PHP corrige en urgence deux failles critiques déjà exploitées contre les sites web
Une faille PHP critique, déjà exploitée, menace WordPress et WooCommerce. Versions corrigées et gestes à faire dès aujourd'hui.
Surnommée « PHP2Shell », la faille PHP corrigée en urgence le 21 octobre 2026 repose en réalité sur deux vulnérabilités critiques, déjà exploitées. Elles permettent de prendre le contrôle d’un serveur web à distance, sans le moindre identifiant. L’équipe PHP a diffusé les versions corrigées dans l’après-midi, alors que des attaques circulaient depuis le matin. Chaque site WordPress, WooCommerce, PrestaShop ou Magento hébergé sur un serveur non corrigé court donc un risque réel.
Le sujet touche directement les commerçants, car le Black Friday approche. Une boutique piratée peut perdre ses données clients ou tomber en panne au pire moment.
Faille PHP : les versions à installer dès maintenant
Le correctif tient en quatre numéros : PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Ils couvrent les quatre branches encore maintenues et règlent deux vulnérabilités distinctes. La première, CVE-2026-109618, exploite la gestion du manque de mémoire. La seconde, CVE-2026-109619, profite de données internes qui traînent en mémoire d’une requête à l’autre.
Chacune obtient une note de gravité CVSS de 9,2 sur 10, soit le niveau « critique ». L’équipe PHP demande d’ailleurs à tous ses utilisateurs de mettre à jour immédiatement, selon son avis de sécurité du 21 octobre. Annoncée la veille, la publication a pourtant été devancée par une fuite d’une partie des détails techniques.
Toutes les installations qui servent des pages web restent exposées : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Le risque grimpe avec mod_php, car une seule requête anonyme suffit à lancer l’attaque, avant même l’exécution du code du site. Les distributions Linux ont reçu les correctifs en avance, donc vérifiez les paquets chez votre fournisseur. Seule ombre signalée : le dépôt bénévole rpms.remirepo.net, prisé sur Red Hat, CentOS et Fedora. Selon Help Net Security, il n’aurait proposé aucune mise à jour le 21 octobre.
WordPress, WooCommerce, PrestaShop : qui risque vraiment quoi
La faille PHP se loge dans le langage lui-même, pas dans un CMS ou une extension. WordPress, Drupal, Magento, Joomla ou Laravel deviennent donc vulnérables dès qu’ils tournent sur une version non corrigée. Les boutiques WooCommerce et PrestaShop, qui reposent aussi sur PHP, se retrouvent en première ligne.
Patchstack a confirmé plusieurs exploitations actives le 21 octobre à 9h34, heure de Paris, soit avant la sortie du correctif. Kevin Beaumont, chercheur en sécurité cité par Help Net Security, parle de « l’une des plus grosses vulnérabilités depuis des années ». Les chercheurs de Wiz, à qui revient l’essentiel de l’analyse technique, estiment aussi que les modèles d’IA les plus avancés ont aidé à rendre exploitable une faille ancienne.
Pour une boutique, le scénario a de quoi inquiéter en plein Q4 : vol des données clients, porte dérobée installée sur le serveur ou site hors ligne. Les boutiques Shopify paraissent moins concernées, puisque la plateforme héberge tout et que le marchand ne gère aucun serveur PHP. Aucune de nos sources ne traite toutefois ce cas : c’est une déduction, pas une confirmation.
Couper le site plutôt que le laisser ouvert
CERT-EU, le service de cybersécurité des institutions européennes, a publié son avis 2026-018. Il recommande de corriger dès que possible et de mettre temporairement hors ligne les sites impossibles à mettre à jour. Le NCSC britannique conseille lui aussi d’envisager de couper les systèmes qu’on ne peut pas corriger tout de suite. Côté français, nous n’avons trouvé aucune alerte de l’ANSSI ni du CERT-FR au moment de publier.
Des mesures provisoires existent, mais elles ne bloquent que certains chemins d’attaque. PHP cite notamment memory_limit=-1, session.upload_progress.enabled=0 ou un post_max_size bas : 8M sans envoi de fichiers, 32M avec. L’équipe prévient elle-même : « il n’existe aucune parade complète, mettre à jour reste le seul choix sûr ».
Cloudflare a déployé de son côté des règles de pare-feu applicatif (WAF) contre les vecteurs d’attaque connus. Elles s’appliquent à tous ses clients, y compris en offre gratuite. Ce filet limite la casse, mais il ne remplace pas le correctif.
PHP 8.2 et 8.1 : l’autre échéance à noter
Cette alerte rappelle aussi le sort des vieilles versions. PHP 8.1 et les branches antérieures ne reçoivent plus de mises à jour du projet. L’équipe a quand même publié des correctifs minimaux pour 7.4, 8.0 et 8.1, réservés aux sites qui compilent PHP eux-mêmes. Ces rustines dépannent, mais elles ne constituent pas un plan durable.
Deuxième date à retenir : PHP 8.2 arrive en fin de vie le 31 décembre 2026. Ensuite, plus aucun correctif de sécurité ne sortira pour cette branche. Un site encore sous 8.2 a donc intérêt à planifier sa migration avant les fêtes, en testant thème et extensions. Laissez en revanche de côté PHP 8.6 : sa version RC3, sortie le 8 octobre, reste une préversion de test.
Cinq vérifications pour protéger votre site de la faille PHP
Sur un hébergement mutualisé, l’hébergeur met en principe PHP à jour lui-même. Sur un serveur dédié ou un VPS, la tâche revient en revanche au propriétaire du site. Nous conseillons cet ordre, à valider avec votre technicien :
- Relevez votre version de PHP dans le tableau de bord de l’hébergeur, ou dans WordPress via Outils > Santé du site.
- Demandez par écrit à votre hébergeur s’il a installé 8.5.12, 8.4.27, 8.3.36 ou 8.2.35.
- Planifiez une migration si le site tourne encore sous PHP 8.1 ou une version plus ancienne.
- Placez le site derrière un pare-feu applicatif, comme celui de Cloudflare, en attendant le correctif.
- Faites contrôler les fichiers modifiés depuis le 20 octobre, afin de repérer une éventuelle porte dérobée.
Si personne ne surveille votre serveur, c’est le bon moment pour régler la question. Snazzy propose par exemple une maintenance de site qui couvre les mises à jour et la sécurité. Nous ignorons encore les mesures prises par les grands hébergeurs français, alors posez-leur la question par écrit.
Vous ne savez pas sur quelle version de PHP tourne votre site ni qui doit la mettre à jour ? L'équipe Snazzy audite gratuitement votre présence en ligne et vous propose une feuille de route claire.
Questions fréquentes
Mon site WordPress risque-t-il quelque chose avec la faille PHP ?
Oui, s'il tourne sur une version de PHP non corrigée. Vérifiez la version dans Outils > Santé du site, puis comparez-la à 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Une version inférieure dans la même branche, ou une branche 8.1 et plus ancienne, reste vulnérable.
Une boutique Shopify doit-elle craindre la faille PHP ?
A priori moins, car Shopify héberge les boutiques et le marchand ne gère aucun serveur PHP. Les sources consultées ne commentent toutefois pas le cas Shopify. Surveillez donc les communications officielles de la plateforme.
Que faire si mon hébergeur n'a pas encore appliqué le correctif ?
Activez un pare-feu applicatif, comme les règles gratuites de Cloudflare, et appliquez les réglages provisoires conseillés par PHP. Ces mesures réduisent le risque sans l'éliminer. CERT-EU recommande même de couper temporairement un site qu'on ne peut pas mettre à jour.
Pourquoi la faille PHP touche-t-elle autant de sites à la fois ?
Le défaut se trouve dans PHP lui-même, et non dans un CMS. Tous les logiciels qui tournent dessus, de WordPress à Magento, héritent donc du problème tant que le serveur reste sur une version vulnérable.
Sources & références
