Faille PHP du 21 octobre 2026 (PHP2Shell) : c’est quoi, qui est concerné, et que faire

Le 21 octobre 2026, le projet PHP a publié en urgence des correctifs pour deux failles critiques, surnommées PHP2Shell (CVE-2026-109618 et CVE-2026-109619). Elles permettent à une personne malveillante de faire exécuter du code par le serveur sans aucun identifiant, à partir d’une simple requête envoyée au site. Les versions corrigées sont PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12. Tout site qui tourne sur une autre version de PHP est concerné, qu’il s’agisse d’un WordPress, d’une boutique WooCommerce ou PrestaShop, d’un Joomla ou d’un site sur mesure.

Voici ce qu’il faut comprendre, et ce qu’il faut faire, sans jargon.

En bref

• La faille est dans PHP lui-même, pas dans WordPress ni dans PrestaShop : un site parfaitement à jour reste exposé si son serveur ne l’est pas.
• Versions sûres : 8.2.35, 8.3.36, 8.4.27, 8.5.12 et au-delà.
• PHP 8.1 et les versions plus anciennes n’ont pas de version corrigée prête à installer. Or PrestaShop 1.7 et PrestaShop 8 ne fonctionnent pas au-delà de PHP 8.1 : ce sont les boutiques les plus exposées.
• À faire aujourd’hui : relever votre version de PHP, la comparer au tableau plus bas, et vérifier que vous avez une sauvegarde récente hors du serveur.

La faille PHP, c’est quoi ?

PHP est le langage qui fait fonctionner la majorité des sites web : WordPress, WooCommerce, PrestaShop, Joomla, Drupal et une bonne partie des sites sur mesure tournent dessus. Chaque fois qu’un visiteur ouvre une page, le serveur lance PHP pour la fabriquer.

Les deux failles du 21 octobre se trouvent dans le cœur de PHP, dans la façon dont il prépare et nettoie chaque requête :

• CVE-2026-109618 : quand la mémoire vient à manquer au mauvais moment, des données internes de la requête restent à moitié préparées, puis sont traitées comme si elles étaient valides ;
• CVE-2026-109619 : un élément interne d’une requête peut survivre à sa fin et être réutilisé par la requête suivante.

Dans les deux cas, une requête fabriquée pour l’occasion peut amener le serveur à exécuter le code de l’attaquant. Le projet PHP note les deux failles 9,2 sur 10 (CVSS 4.0).

Point important : sur les serveurs qui utilisent Apache avec mod_php, la configuration la plus exposée, l’attaque se déclenche avant même que le code de votre site ne s’exécute. Le mot de passe de votre administration, vos extensions de sécurité WordPress ou vos modules PrestaShop ne servent donc à rien contre elle. Tous les autres modes de fonctionnement de PHP sont touchés aussi : PHP-FPM, php-cgi, FrankenPHP, LiteSpeed.

Pourquoi on l’appelle PHP2Shell, et pourquoi tout le monde en parle

« Shell » désigne l’accès à la ligne de commande d’un serveur : obtenir un shell, c’est pouvoir y faire ce que l’on veut. Les détails des failles ont fuité sur un forum avant la date prévue, ce qui a obligé le projet PHP à annoncer la mise à jour la veille, le 20 octobre, puis à la publier le 21 à 14 h (heure de Paris : 16 h). Un exploit fonctionnel a été démontré, et les explications techniques circulent depuis la fuite.

Le 21 octobre au soir, ni le projet PHP ni le CERT-FR (l’agence française de réponse aux incidents) ne signalent d’attaque constatée. Mais avec des détails publics et des millions de serveurs concernés, il faut considérer les attaques comme imminentes : c’est une course entre les correctifs et les attaquants.

Faille PHP : quelles versions sont touchées ?

Toutes les versions de PHP antérieures aux versions corrigées sont touchées, de PHP 5 à PHP 8.5.11.

Pour PHP 7.4, 8.0 et 8.1, l’équipe de sécurité de PHP a publié des correctifs de code source minimaux. Ils ne servent qu’à ceux qui compilent PHP eux-mêmes, ou aux distributions et éditeurs qui assurent un support prolongé. Sur un hébergement classique, cela revient à dire : pas de version corrigée à installer.

WordPress, WooCommerce, PrestaShop : votre site est-il concerné ?

Oui, s’il tourne sur une version de PHP non corrigée. Le logiciel n’y est pour rien, mais c’est lui qui décide jusqu’à quelle version de PHP vous pouvez monter.

Faille PHP et WordPress ou WooCommerce

Votre version de PHP s’affiche dans Outils › Santé du site › Infos › Serveur. WordPress récent fonctionne en PHP 8.2, 8.3 et 8.4, et WooCommerce aussi. Le frein vient le plus souvent d’une vieille extension ou d’un thème abandonné, qui refuse de tourner sur un PHP récent : c’est à tester sur une copie du site avant de changer de version.

Si votre WordPress n’a pas été mis à jour depuis des années, la montée de version de PHP passera par sa mise à jour, et souvent par le remplacement de quelques extensions.

Faille PHP et PrestaShop : les boutiques les plus exposées

Votre version de PHP s’affiche dans Paramètres avancés › Informations. C’est là que le bât blesse :

• PrestaShop 1.7 ne fonctionne pas avec PHP 8 : il tourne en PHP 7.x, qui n’a aucune version corrigée.
• PrestaShop 8.0 à 8.2 fonctionne jusqu’à PHP 8.1, version recommandée par l’éditeur, et pas au-delà. Or PHP 8.1 n’a pas de version corrigée prête à installer.
• PrestaShop 9 accepte PHP 8.1 à 8.4 selon la version, et peut donc passer sur une version corrigée.

Autrement dit, une boutique en PrestaShop 1.7 ou 8 ne peut pas être protégée par une simple mise à jour de PHP. La seule issue durable est la migration vers PrestaShop 9 ; en attendant, il faut réduire l’exposition en amont de la boutique (voir plus bas). Nous détaillons les étapes dans notre guide migrer vers PrestaShop 9.

Joomla, Drupal, Magento, sites sur mesure

Même logique : relevez la version de PHP du serveur, puis vérifiez dans la documentation de votre logiciel, ou auprès de votre prestataire, jusqu’à quelle version il peut monter.

Que faire, dans l’ordre

1. Relevez votre version de PHP. Dans l’administration du site (voir plus haut), ou dans l’espace client de votre hébergeur, à la rubrique de configuration PHP.
2. Si elle est en 8.2 ou plus : vérifiez que le dernier chiffre correspond au tableau. Si ce n’est pas le cas, voyez avec votre hébergeur quand il installe la version corrigée (étape suivante).
3. Si elle est en 8.0 ou 8.1 : passez en 8.2 ou plus dès que votre site le permet, après un test sur une copie. Si c’est une boutique PrestaShop 8, ce n’est pas possible sans migration : voir plus haut.
4. Si elle commence par 7 : il n’existe pas de version corrigée. La seule issue durable est la mise à jour de votre logiciel vers une version compatible avec un PHP récent, ou la migration du site. En attendant, une protection en amont du site limite l’exposition ; elle demande une intervention technique.
5. Dans tous les cas : vérifiez que vous avez une sauvegarde récente hors du serveur. Si le serveur est compromis, une sauvegarde rangée dessus ne vaut plus rien.

Mettre à jour PHP chez votre hébergeur : OVH, o2switch, Ionos, Infomaniak, Hostinger

Sur un hébergement mutualisé, vous ne pouvez pas installer PHP vous-même : c’est l’hébergeur qui installe les versions corrigées, selon son propre calendrier. Le 21 octobre, certains l’avaient fait dans l’après-midi, d’autres préparaient encore leurs paquets en fin de journée, et d’autres ont d’abord ajouté des règles de filtrage devant les sites.

Ce que vous pouvez faire de votre côté :

• Choisir la branche de PHP (8.1, 8.2, 8.3…) : tous les hébergeurs cités proposent ce réglage par site, dans l’espace client. C’est ce réglage qu’il faut changer pour quitter PHP 8.1 ou 7.x, après un test.
• Vérifier le numéro exact une fois la journée passée, dans l’administration du site : il doit correspondre au tableau.
• Écrire au support si le numéro ne bouge pas, en citant les deux CVE : CVE-2026-109618 et CVE-2026-109619.

Vous administrez votre serveur (VPS, serveur dédié)

Mettez à jour les paquets PHP de votre distribution, puis redémarrez PHP-FPM ou Apache. Les éditeurs de distributions ont reçu les correctifs à l’avance. Attention : sur Debian ou Ubuntu, le numéro de PHP peut rester le même, le correctif étant intégré au paquet de la distribution. C’est alors la version du paquet qui fait foi, à comparer au bulletin de sécurité de votre distribution. Le dépôt communautaire Remi n’avait pas encore de paquets corrigés le jour de l’annonce.

Si vous ne pouvez pas mettre à jour tout de suite, le projet PHP et le CERT-FR proposent des mesures d’attente. Elles réduisent l’exposition, sans la supprimer :

• session.upload_progress.enabled = 0
• memory_limit = -1
• post_max_size = 8M (32M si le site reçoit des fichiers), avec upload_max_filesize toujours inférieur

Quelques précautions :

• Ces réglages doivent être appliqués dans php.ini ou dans le pool PHP-FPM, puis tous les workers redémarrés : ni ini_set() ni un fichier .user.ini ne suffisent.
• session.upload_progress.enabled = 0 ne protège que contre l’une des deux failles.
• Le CERT-FR suggère aussi de filtrer, sur un pare-feu applicatif, les requêtes envoyées en multipart (celles des formulaires avec fichiers), ou au moins de les surveiller.

La mise à jour reste la seule correction complète.

Mon site a-t-il été attaqué ?

À l’heure où nous écrivons, aucune attaque n’est confirmée par les sources officielles. Restez attentif dans les jours qui viennent à ces signes :

• des fichiers PHP inconnus ou récemment modifiés sur le serveur, surtout dans les dossiers d’images ou de cache ;
• un compte administrateur que vous n’avez pas créé ;
• des redirections vers d’autres sites, des pages de spam, ou un avertissement de Google dans les résultats ;
• un serveur soudain lent, ou un hébergeur qui vous signale un envoi massif d’e-mails.

Si vous constatez l’un de ces signes, ne supprimez rien à la hâte : relevez ce que vous voyez, et faites examiner le site. Notre guide site WordPress piraté : que faire donne les premiers gestes, et notre intervention de sécurité prend le relais.

Pourquoi « mettre à jour » n’est pas « maintenir »

Mettre à jour, c’est appuyer sur un bouton. Maintenir, c’est savoir qu’il faut appuyer, le jour même, sur le bon bouton, sans casser le reste, et vérifier après.

Le 21 octobre, sur les serveurs que nous administrons pour nos clients, le correctif a été installé dans les minutes qui ont suivi sa publication. Aucun de ces clients n’a eu à lire cet article pour être protégé.

C’est ce que couvre notre maintenance mensuelle Boost, dès 99 € HT par mois et sans engagement : mises à jour testées sur une copie avant d’être installées, faille critique corrigée sous 48 heures sans attendre la mise à jour du mois, sauvegardes chaque jour avec une copie hors du serveur chaque semaine, hébergement en France et dépannage compris.

Questions fréquentes

PHP2Shell, c’est quoi ?

C’est le surnom de deux failles critiques de PHP, CVE-2026-109618 et CVE-2026-109619, corrigées le 21 octobre 2026. Elles permettent d’exécuter du code sur un serveur sans identifiant, à partir d’une requête web.

Quelle version de PHP est sûre ?

PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12, ou toute version plus récente de ces branches. PHP 8.2 n’aura plus de correctifs après le 31 décembre 2026 : si vous changez de branche maintenant, visez 8.3 ou 8.4.

PHP 8.1 est-il encore sûr ?

Non. PHP 8.1 ne reçoit plus de versions corrigées de la part du projet PHP. Seuls les éditeurs qui assurent un support prolongé peuvent appliquer les correctifs de code source publiés.

Mon site WordPress est à jour : suis-je protégé ?

Pas forcément. La faille est dans PHP, pas dans WordPress. Un WordPress à jour sur un PHP non corrigé reste exposé. Vérifiez la version de PHP dans Outils › Santé du site.

Ma boutique PrestaShop 1.7 ou 8 peut-elle être protégée ?

Pas par une simple mise à jour de PHP, puisque ces versions ne fonctionnent pas au-delà de PHP 8.1. Une protection en amont limite l’exposition en attendant, et la migration vers PrestaShop 9 règle le problème durablement.

Faut-il changer d’hébergeur ?

Pas pour cette seule faille. En revanche, si votre hébergeur ne vous dit pas quand il installe les versions corrigées, ou si personne ne peut vous répondre dans la journée, c’est ce point-là qu’il faut régler.

Sources

• Projet PHP, annonces des 20 et 21 octobre 2026 : php.net
• Avis de sécurité GHSA-w8hw-w9fx-j79w (CVE-2026-109618) et GHSA-6wmf-4rv5-p3rp (CVE-2026-109619) : github.com/php/php-src
• CERT-FR, alerte CERTFR-2026-ALE-014 : cert.cyber.gouv.fr
• PrestaShop, configuration requise de la version 8 : devdocs.prestashop-project.org