PHP2Shell : que faire maintenant pour votre site WordPress ou Laravel

Mis à jour le 21 octobre 2026, 16:30 (heure de Paris) : le correctif est disponible. Passez à PHP 8.2.35, 8.3.36, 8.4.27 ou 8.5.12. Les commandes sont à l'étape 3.

Deux failles de sécurité critiques dans PHP ont fuité le 20 octobre, avant qu'un correctif ne soit prêt. Elles s'appellent PHP2Shell et sont référencées CVE-2026-109618 et CVE-2026-109619. L'équipe de sécurité de PHP elle-même les note 9,2 sur 10. Un attaquant peut envoyer une seule requête spécialement conçue à votre site et exécuter son propre code sur votre serveur, sans mot de passe. Les attaques ont déjà commencé. Aux Pays-Bas, la Chambre des représentants, le Centre national de cybersécurité et Tweakers ont mis leurs sites hors ligne par précaution.

Si votre site tourne sur PHP, vous êtes concerné. Cela inclut presque tous les sites WordPress et WooCommerce, toutes les applications Laravel, ainsi que Magento, Shopware et Drupal. Voici quoi faire, dans l'ordre.

Pas le temps, ou pas de développeur sous la main ? Nous corrigeons votre serveur aujourd'hui : mise à jour de PHP, fermeture de ce qui ne devrait pas être ouvert, vérification d'une éventuelle intrusion et envoi d'un court rapport. Demander une aide d'urgence →

Ce qui se passe, en termes simples

Les bugs sont dans PHP lui-même, dans la façon dont il traite une requête web : l'un se déclenche quand PHP manque de mémoire alors qu'il lit encore une requête, l'autre quand des données d'une requête survivent dans la suivante. Les deux se produisent avant l'exécution du code de votre site, c'est pourquoi mettre à jour WordPress ou les extensions ne sert à rien. Toutes les configurations qui servent des pages web sont concernées : mod_php (le risque le plus élevé), PHP-FPM, php-cgi, FrankenPHP et LiteSpeed. PHP ne prend en charge que la version 8.2 et les suivantes ; pour 8.1 et antérieures, l'équipe PHP a publié des correctifs rétroportés, pas de nouvelles versions.

Votre situation	Que faire	Urgence
Hébergement mutualisé ou géré (la plupart des sites WordPress)	Consultez la page de statut de votre hébergeur ; demandez quand il applique le correctif et quelle version de PHP vous utilisez	Aujourd'hui
Votre propre serveur, VPS ou instance cloud	Installez la mise à jour de PHP dès qu'elle est disponible ; protégez le serveur en attendant (voir ci-dessous)	Aujourd'hui
Docker ou conteneurs	Reconstruisez l'image sur l'image de base PHP corrigée et redéployez	Aujourd'hui
PHP 8.1 ou plus ancien	Passez à PHP 8.2 ou plus récent ; gardez le site verrouillé d'ici là	Aujourd'hui, et planifiez la migration
Boutique en ligne ou site avec données clients que vous ne pouvez pas corriger aujourd'hui	Mettez-le en maintenance ou n'autorisez que la consultation des pages (requêtes GET)	Maintenant

Étape 1 : faites une sauvegarde maintenant

Faites une sauvegarde complète de vos fichiers et de votre base de données, et stockez-la ailleurs que sur le serveur lui-même. Si quelque chose tourne mal dans les prochaines heures, une sauvegarde saine d'avant est le moyen le plus rapide de revenir en arrière.

Étape 2 : protégez le serveur en attendant le correctif

Aucune de ces mesures ne corrige le bug, mais elles rendent une attaque plus difficile :

• Appliquez les réglages provisoires de PHP. Dans php.ini ou votre pool FPM (pas dans .user.ini ni avec ini_set()), définissez session.upload_progress.enabled = 0, memory_limit = -1, post_max_size = 8M (32M si vous avez besoin d'uploads) et upload_max_filesize = 4M. Sur PHP 8.5, définissez aussi fatal_error_backtraces = 0. Puis redémarrez PHP-FPM ou votre serveur web. PHP lui-même indique que ces réglages réduisent le risque mais ne rendent pas un serveur sûr.
• Fermez la porte dérobée. Si vous utilisez Cloudflare ou un autre CDN, faites en sorte que votre serveur n'accepte le trafic que depuis les plages d'IP de ce CDN. Leurs règles de pare-feu ne servent que si les attaquants ne peuvent pas joindre directement votre serveur.
• Bloquez les uploads là où vous n'en avez pas besoin. Rejeter les requêtes multipart/form-data dans nginx ou Apache arrête cette attaque, mais casse aussi l'envoi de fichiers, ainsi que certains formulaires et paiements. Testez d'abord.
• Mettez les sites à haut risque hors ligne. Pour une boutique ou un site avec des données clients que vous ne pouvez pas corriger aujourd'hui, une page de maintenance est plus sûre que de rester en ligne. Vous pouvez aussi n'autoriser que les requêtes GET et HEAD pour que les pages continuent de s'afficher.

N'installez pas d'extensions « correctives » non officielles et ne collez pas d'extraits de code trouvés sur des forums. Ils peuvent aggraver la situation.

Étape 3 : installez la mise à jour de PHP

Les versions corrigées sont disponibles depuis le 21 octobre 2026 :

Vous utilisez	Passez au minimum à
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35 (fin du support le 31 décembre 2026, planifiez donc une migration)
PHP 8.1 ou plus ancien	Pas de nouvelle version : passez à 8.2 ou plus récent, ou demandez à votre fournisseur un paquet rétroporté

• Ubuntu ou Debian : sudo apt update && sudo apt upgrade, puis sudo systemctl restart php8.3-fpm (selon votre version) ou sudo systemctl restart apache2 pour mod_php. Les distributions rétroportent le correctif dans leurs propres numéros de version, le numéro peut donc différer : consultez l'avis de sécurité de votre distribution plutôt que php -v. Sur le dépôt ondrej/sury, les numéros de version correspondent au tableau.
• RHEL, AlmaLinux ou Rocky : sudo dnf upgrade 'php*', puis redémarrez PHP-FPM ou Apache.
• Docker : reconstruisez avec la dernière image officielle, par exemple docker build --pull . sur php:8.4-fpm, et redéployez chaque conteneur.
• Hébergement géré ou mutualisé : votre hébergeur l'installe. Demandez-lui de confirmer la date et la version, et vérifiez que votre site tourne en 8.2 ou plus récent.

Redémarrez tous les workers PHP après la mise à jour : les anciens workers continuent d'exécuter le code vulnérable. Vérifiez ensuite avec php -v en ligne de commande et avec une page phpinfo() que vous supprimez aussitôt après.

Étape 4 : vérifiez si quelqu'un est entré

Les bugs sont publics depuis le 20 octobre : un serveur en ligne et non corrigé a donc pu déjà être touché. Après la mise à jour, vérifiez :

• Les fichiers .php nouveaux ou modifiés dans les dossiers d'upload : wp-content/uploads pour WordPress, storage/ et public/ pour Laravel.
• Les utilisateurs admin que vous ne reconnaissez pas, dans WordPress ou dans votre panneau d'hébergement.
• Les nouvelles tâches cron ou planifiées.
• Les fichiers du cœur de WordPress modifiés récemment, et les redirections vers des sites inconnus.

Vous avez trouvé quelque chose ? Ne vous contentez pas de supprimer les fichiers suspects. Restaurez une sauvegarde saine d'avant le 20 octobre, appliquez le correctif et changez tous les mots de passe : admin, hébergement, base de données, SFTP et clés d'API. Si vous utilisez UpdraftCentral, supprimez aussi ses clés de tableau de bord : des attaquants utilisent des clés divulguées pour installer des portes dérobées, un problème distinct et actif en ce moment.

Après cette semaine

• Gardez PHP sur une version prise en charge (8.2 ou plus récente) et mettez-le à jour dans le cadre de la maintenance normale, pas seulement en cas de crise.
• Assurez-vous que votre serveur n'accepte le trafic web que sur les ports 80 et 443. Les bases de données et les ports d'administration ne doivent jamais être ouverts à tout Internet.
• Conservez des sauvegardes quotidiennes en dehors de votre compte d'hébergement, et testez une restauration au moins une fois.
• Notez qui héberge votre site, quelle version de PHP il utilise et qui peut s'y connecter. Cette semaine a montré combien de temps cela fait gagner.

Besoin d'aide aujourd'hui ?

Envoyez-nous l'adresse de votre site et nous commençons aujourd'hui. Un développeur senior vérifie quelle version de PHP votre site utilise, installe le correctif ou verrouille le site jusqu'à ce qu'il puisse être corrigé, et recherche une éventuelle intrusion. Vous recevez un court rapport de ce que nous avons trouvé et de ce que nous avons modifié. Hébergeur, agence ou serveur personnel : nous travaillons avec ce que vous avez.

Demander une aide d'urgence → ou contactez-nous.

Sources : Sansec, Patchstack, CERT-EU via The Next Web, NL Times.