Vérifier et corriger la faille PHP2Shell sur un site WordPress ou Laravel

Si vous avez un site WordPress, une boutique WooCommerce ou une application Laravel hébergés en mutualisé, cet article vous concerne. Le 21 octobre 2026, le projet PHP a corrigé deux failles critiques, surnommées « PHP2Shell » (CVE-2026-109618 et CVE-2026-109619), qui peuvent permettre à un inconnu d'exécuter du code sur le serveur sans se connecter. Vous saurez ici vérifier votre version de PHP, quoi demander à l'hébergeur, ce que valent les mesures provisoires et quels signes chercher.

Le contexte en quelques lignes : pourquoi des sites publics ont été coupés

Le 21 octobre après-midi, plusieurs sites de préfectures, le site du ministère de l'Économie et celui de Météo-France sont devenus inaccessibles. Selon le ministère de l'Intérieur, cité par franceinfo, ces coupures ont été faites à la demande de l'ANSSI. Le lendemain, d'après France 2, le site des impôts et les comptes de l'Assurance maladie étaient aussi bloqués, au titre d'une « mise en maintenance préventive ».

Le score officiel des deux failles est de 9,2 sur 10 (CVSS 4.0), selon les avis publiés par le projet PHP sur GitHub.

1. Comprendre que la faille PHP2Shell est dans PHP, pas dans WordPress ou Laravel

Les deux failles touchent sa gestion de la mémoire et des erreurs. La première (CVE-2026-109618) survient quand une requête atteint sa limite de mémoire au mauvais moment. Pour la seconde (CVE-2026-109619), un état interne lié à une requête survit après la libération de sa mémoire, et une requête suivante traitée par le même processus PHP peut l'utiliser.

Conséquence pratique : WordPress indique qu'aucune mise à jour de WordPress n'est requise ni prévue pour ces failles. Mettre à jour extensions ou Laravel ne corrige rien : seule la version de PHP compte.

Le projet PHP juge le risque maximal avec Apache et mod_php, mais PHP-FPM, php-cgi, FrankenPHP et LiteSpeed sont aussi touchés. Une extension de sécurité ne suffit pas : sur mod_php, le projet PHP a démontré qu'une requête non authentifiée peut déclencher l'attaque avant que le code de l'application ne s'exécute. Une extension de sécurité WordPress s'exécute dans l'application : dans ce cas, elle arrive trop tard.

2. Vérifier la version de PHP qui sert réellement votre site

Les versions corrigées, publiées le 21 octobre après-midi, sont :

• PHP 8.5.12 pour la branche 8.5 ;
• PHP 8.4.27 pour la branche 8.4 ;
• PHP 8.3.36 pour la branche 8.3 ;
• PHP 8.2.35 pour la branche 8.2.

Toute version antérieure dans ces branches est vulnérable.

Seule compte la version qui sert les pages web : en mutualisé, php -v en SSH ou php artisan about peuvent afficher une autre version. Sur WordPress ou WooCommerce, le plus simple est l'écran Outils > Santé du site > Informations > Serveur.

Sur Laravel ou un autre site, déposez à la racine publique un fichier au nom difficile à deviner contenant seulement <?php echo PHP_VERSION;, ouvrez-le dans le navigateur, puis supprimez-le aussitôt.

Certains hébergeurs peuvent appliquer le correctif sans changer le numéro affiché. Lisez son annonce ou posez-lui la question.

3. Passer à une version corrigée, ou la demander à votre hébergeur

En mutualisé, c'est l'hébergeur qui met à jour PHP. À votre portée : choisir dans le panneau la version corrigée de votre branche, ou une branche supérieure. Si le panneau ne le permet pas, ouvrez un ticket en citant les deux identifiants CVE-2026-109618 et CVE-2026-109619, et demandez une confirmation écrite.

En PHP 8.1 ou plus ancien, le projet PHP ne publie plus de version, seulement des correctifs minimaux en code source pour 7.4, 8.0 et 8.1. En mutualisé, la voie réaliste est de passer en 8.2 au minimum, après un test de compatibilité sur une copie du site. PHP 8.2 ne recevra plus de correctifs après le 31 décembre 2026, selon le projet PHP.

4. Connaître les mesures provisoires et leurs limites

Seule la mise à jour protège vraiment. L'avis du projet PHP liste des mesures temporaires, toutes partielles, séparées par faille.

Pour CVE-2026-109618, l'avis cite memory_limit=-1 imposé côté serveur, en précisant qu'une défaillance d'allocation peut encore atteindre le code vulnérable ; ce réglage retire aussi toute limite de mémoire. Il conseille aussi un post_max_size bas (8M sans envoi de fichiers, 32M sinon, avec upload_max_filesize en dessous), des limites posées par le serveur web ou le proxy sur la taille des requêtes et le nombre de champs, et une limite de mémoire par conteneur ou cgroup. Il met en garde contre RLIMIT_AS et RLIMIT_DATA, qui peuvent au contraire déclencher la faille. Aucune de ces mesures ne rend le serveur sûr.

Pour CVE-2026-109619 (état interne) :

• session.upload_progress.enabled=0, puis redémarrage de tous les processus PHP, dans php.ini, le pool PHP-FPM ou la configuration du serveur, pas avec ini_set() ni le .user.ini. Il ne bloque que les chemins confirmés qui passent par les sessions ;
• sur PHP 8.5, fatal_error_backtraces=0, qui ne bloque qu'un seul chemin ;
• supprimer les réglages invalides ou dépréciés qui produisent des messages avant l'initialisation (les masquer ne sert à rien) ;
• corriger les erreurs fatales et les dépassements de temps qu'un attaquant peut provoquer.

En mutualisé, ces réglages se demandent à l'hébergeur : utilisez son panneau s'il propose la version corrigée, sinon ouvrez un ticket. Un réglage modifié par vous dans un fichier du site ne compte pas.

Aucun réglage php.ini ni aucune extension de sécurité ne suffit à protéger le site. Le CERT-FR cite le blocage des requêtes multipart par un pare-feu applicatif, mais il précise que cette mesure n'est pas qualifiée. Une page de maintenance affichée par le site ne sert à rien : PHP reçoit toujours les requêtes. Une boutique sensible qu'on ne peut pas mettre à jour vite doit plutôt sortir temporairement d'Internet, comme le recommandent le CERT-FR et le CERT-EU.

5. Chercher des signes possibles d'exploitation depuis le 17 octobre

Sophos signale des tentatives depuis au moins le 17 octobre 2026 et conseille, par précaution, de remonter au 1er août. Premier réflexe : téléchargez tout de suite vos journaux, car les hébergements mutualisés ne les gardent souvent que quelques jours. Ensuite, regardez. Ce sont des signes généraux d'attaque ou d'intrusion, pas des indicateurs officiels publiés par le projet PHP.

• dans les journaux d'erreurs : des pics de « Allowed memory size … exhausted » sur des requêtes POST, et des plantages en série (segfault, SIGSEGV, « child exited ») ;
• dans les journaux d'accès : des rafales de POST multipart/form-data depuis une même adresse IP vers des pages qui n'attendent pas de fichier, avec des réponses 500 ou 502, ou des requêtes contenant le champ PHP_SESSION_UPLOAD_PROGRESS ;
• sur le site : des fichiers .php récents dans uploads, cache ou storage/app/public, des fichiers modifiés, des comptes administrateur inconnus, de nouvelles tâches cron, des e-mails sortants anormaux.

Si vous trouvez un fichier suspect, voyez la vérification après une faille d'extension WordPress. Côté Laravel, comparer le dossier vendor à une version connue aide à repérer une modification.

6. Savoir où en est l'exploitation aujourd'hui

Amazon a signalé une tentative le 17 octobre, avant la publication, et d'autres tentatives rapportées depuis. Le 21 octobre, au moment de la publication, la fondation PHP n'avait identifié aucun code d'attaque fonctionnel. Le même jour, dans la mise à jour de son avis, le CERT-EU indiquait que des preuves de concept circulaient, ce qui augmente la probabilité d'une exploitation ; le CERT-FR signale aussi des preuves de concept le 22 octobre.

Le projet PHP rappelle que l'absence de trace dans un journal n'est pas une preuve.

Ce qu'il faut retenir

La faille PHP2Shell est dans PHP : ni WordPress, ni WooCommerce, ni Laravel, ni une extension ne la corrigent. Vérifiez la version web (8.2.35, 8.3.36, 8.4.27, 8.5.12 ou plus), ou obtenez de l'hébergeur la confirmation du correctif. En 8.1 ou avant, passez en 8.2 minimum après test. Les mesures provisoires sont partielles et relèvent de l'hébergeur. Sauvegardez vos journaux et cherchez des traces depuis le 17 octobre.

En cas de doute après ces vérifications, changez les mots de passe et les clés (clés secrètes WordPress, APP_KEY et fichier .env de Laravel, base de données), restaurez une sauvegarde saine, et faites-vous accompagner : c'est ce que couvre notre offre de maintenance.