Failles PHP : ce qu'une PME e-commerce doit vérifier sur son site

Si votre site e-commerce tourne sous WordPress, WooCommerce, PrestaShop ou Magento, il repose sur PHP, et deux failles critiques de ce langage permettent depuis le 21 octobre 2026 de prendre le contrôle d'un serveur à distance, sans mot de passe. La seule vraie protection est la mise à jour de PHP vers les versions 8.5.12, 8.4.27, 8.3.36 ou 8.2.35. Une PME n'a pas besoin d'être développeuse pour s'en assurer : il lui suffit de poser trois questions précises à son hébergeur ou à son prestataire, et de vérifier la réponse.

Que s'est-il passé avec PHP en octobre 2026 ?

L'équipe de PHP a corrigé en urgence deux vulnérabilités notées 9,2 sur 10, qui permettent d'exécuter du code sur un serveur sans s'authentifier. Elles ont été annoncées le 20 octobre et corrigées le 21 octobre 2026.

Selon l'annonce officielle de PHP du 21 octobre 2026, les failles CVE-2026-109618 et CVE-2026-109619 touchent toutes les installations qui répondent à des requêtes web : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Traduction pour un dirigeant : à peu près toutes les façons d'héberger un site PHP. L'équipe de PHP juge le risque le plus élevé pour mod_php, où une seule requête anonyme suffit à déclencher l'attaque avant même que le code du site ne s'exécute.

Le CERT-EU, l'équipe de réponse aux incidents des institutions européennes, a signalé le 21 octobre 2026 que des preuves de concept circulaient déjà, c'est-à-dire des démonstrations techniques que des pirates peuvent réutiliser. Le CERT-FR, rattaché à l'ANSSI, indiquait dans sa mise à jour du 26 octobre 2026 constater des tentatives d'exploitation. D'après le Blog du Modérateur du 22 octobre 2026, plusieurs administrations françaises, dont le ministère de l'Intérieur, ont mis des services hors ligne le temps de la mise à jour.

Pourquoi une boutique en ligne est-elle concernée au premier chef ?

Parce que PHP fait tourner la majorité du web marchand, et qu'un serveur compromis expose vos commandes, vos comptes clients et votre réputation. Le défaut est dans le langage lui-même, pas dans votre code.

D'après W3Techs, PHP équipait au 29 octobre 2026 69,2 % des sites dont le langage serveur est connu. WordPress et WooCommerce, PrestaShop, Magento ou Drupal en dépendent. Un site parfaitement entretenu reste donc vulnérable si la version de PHP installée sur le serveur n'est pas corrigée.

Pour une boutique, le diagnostic est vite posé. Un attaquant qui exécute du code sur votre serveur peut lire la base de données des clients, glisser un faux formulaire de paiement, rediriger vos visiteurs ou se servir de votre site pour envoyer du spam. Les dégâts ne se limitent pas à la technique : un avertissement « site dangereux » dans le navigateur en pleine période de fêtes, et c'est le chiffre d'affaires de novembre qui part en convalescence.

Comment savoir si mon site est à jour ?

Demandez la version exacte de PHP active sur chaque site et comparez-la aux versions corrigées. Sous WordPress, l'information figure dans l'outil « Santé du site », rubrique Infos puis Serveur.

Voici le seuil à atteindre pour chaque branche, selon le CERT-FR :

Branche de PHP	Version corrigée minimale
8.5	8.5.12
8.4	8.4.27
8.3	8.3.36
8.2	8.2.35
8.1 et antérieures	plus de correctif officiel : migrer

Un piège mérite d'être connu. L'hébergeur GoDaddy explique dans sa note du 22 octobre 2026 que, sur ses offres mutualisées, le correctif a été appliqué sans changer le numéro de version : un site peut afficher 8.5.11 tout en étant protégé. Le numéro seul ne suffit donc pas, il faut une confirmation écrite de l'hébergeur, avec la date d'application du correctif.

Et si mon site tourne sur une vieille version de PHP ?

C'est le cas le plus risqué : les branches 8.1 et antérieures ne reçoivent plus de mises à jour du projet PHP. Il faut prévoir une migration vers une version maintenue, ou à défaut un correctif fourni par un éditeur spécialisé.

Le sujet est loin d'être marginal. Toujours selon W3Techs, au 29 octobre 2026, 26,5 % des sites PHP tournaient encore en version 7 et 7,7 % en version 5. Le projet PHP a fourni à titre exceptionnel des correctifs minimaux pour les branches 7.4, 8.0 et 8.1, mais il les réserve à ceux qui compilent PHP eux-mêmes et recommande de passer à une version maintenue.

Une vieille version de PHP est rarement un oubli isolé. Elle signale souvent un thème, des extensions ou un module de paiement qui n'ont pas été mis à jour depuis longtemps, parce que personne n'ose y toucher. C'est l'occasion de faire le bilan de santé complet plutôt qu'un pansement de plus.

Qui doit faire la mise à jour : moi, mon hébergeur ou mon prestataire ?

Tout dépend de votre hébergement. Sur un hébergement mutualisé ou infogéré, c'est l'hébergeur ; sur un serveur dédié ou un VPS (serveur privé virtuel), c'est vous ou votre prestataire technique.

• Hébergement mutualisé ou WordPress infogéré : l'hébergeur applique en principe le correctif. Votre travail consiste à obtenir sa confirmation par écrit.
• VPS ou serveur dédié : personne ne le fera à votre place. Les distributions Linux ont reçu les correctifs en avance, selon PHP ; il faut installer les paquets mis à jour puis redémarrer PHP et le serveur web.
• Panneau cPanel ou Plesk : la version se change depuis le panneau de contrôle, après une sauvegarde.
• Plateforme hébergée de type Shopify : vous ne gérez pas de serveur PHP, c'est la plateforme qui en a la charge.

Attention aussi aux logiciels qui embarquent PHP sans le dire : un outil de facturation, un intranet ou une ancienne boutique de test restée en ligne. Le CERT-EU recommande de recenser toutes les installations, pas seulement le site principal.

Que faire si la mise à jour ne peut pas être immédiate ?

Isoler le site d'Internet jusqu'au correctif, comme le recommandent le CERT-FR et le CERT-EU, et appliquer en attendant les contournements publiés par PHP. Ces mesures réduisent l'exposition, mais l'équipe de PHP les qualifie elle-même d'incomplètes.

Concrètement, une page de maintenance de quelques heures coûte moins cher qu'une base clients dérobée. Si votre site est resté exposé plusieurs jours sans correctif, le CERT-FR renvoie vers sa fiche réflexe consacrée à la compromission d'un équipement de bordure réseau : elle liste les premières actions pour vérifier qu'aucun intrus ne s'est installé. Un dernier point : le 23 octobre 2026, PHP a signalé une troisième faille, CVE-2026-115560, qui ne concerne que des configurations inhabituelles et sera corrigée lors de la prochaine version régulière. Le réglage recommandé en attendant est session.upload_progress.enabled = 0, à transmettre tel quel à votre prestataire.

Mon ordonnance

1. Cette semaine, envoyez trois questions à votre hébergeur ou prestataire : quelle version de PHP tourne sur chacun de mes sites ? Le correctif du 21 octobre 2026 est-il appliqué, et à quelle date ? Le réglage recommandé pour la faille du 23 octobre est-il en place ?
2. Faites l'inventaire de tout ce qui tourne en PHP, y compris les sites oubliés, les sous-domaines de test et les outils internes.
3. Programmez la migration de toute branche 8.1 ou plus ancienne, en commençant par une sauvegarde complète et un test sur une copie du site.
4. Abonnez-vous aux alertes du CERT-FR pour ne plus découvrir ce genre de faille dans la presse.
5. Inscrivez la mise à jour de PHP dans votre contrat de maintenance, avec un délai d'application écrit pour les failles critiques.

Ce que j'en retiens, après trente ans de sites marchands : les pannes qui coûtent le plus cher sont rarement les plus spectaculaires. Ce sont les petites mises à jour que tout le monde croyait faites par quelqu'un d'autre. Une question posée à temps à votre hébergeur vaut mieux que dix ordonnances après l'incident.

Questions fréquentes

Mon site WordPress est-il concerné par les failles PHP d'octobre 2026 ?

Très probablement, car WordPress et WooCommerce fonctionnent avec PHP. Les failles touchent toutes les installations qui répondent à des requêtes web, quelle que soit la façon dont le serveur est configuré. Votre site est protégé seulement si votre hébergeur a installé PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou s'il confirme par écrit avoir appliqué le correctif du 21 octobre 2026.

Mon site affiche une version de PHP plus ancienne : suis-je en danger ?

Pas forcément. Chez certains hébergeurs mutualisés, comme GoDaddy, le correctif a été appliqué sans changer le numéro de version affiché. Le seul moyen d'être sûr est de demander à votre hébergeur une confirmation écrite, avec la date d'application du correctif. Si votre site tourne en PHP 8.1 ou plus ancien, prévoyez en revanche une migration, car ces versions ne sont plus suivies.

Ma boutique Shopify est-elle exposée à ces failles PHP ?

Non, pas directement. Sur une plateforme hébergée comme Shopify, vous ne gérez pas de serveur PHP, et c'est la plateforme qui s'occupe de la sécurité de son infrastructure. Vérifiez quand même vos autres outils : un blog WordPress à côté de la boutique, un ancien site de test resté en ligne ou un logiciel interne peuvent, eux, tourner en PHP.

Que faire si je ne peux pas mettre PHP à jour tout de suite ?

Le CERT-FR et le CERT-EU recommandent d'isoler les serveurs concernés d'Internet jusqu'à la mise à jour, par exemple avec une page de maintenance. En attendant, votre prestataire peut appliquer les contournements publiés par l'équipe PHP, qui réduisent le risque sans le supprimer. Si le site est resté plusieurs jours sans correctif, faites vérifier qu'aucun intrus ne s'y est installé.

Sources

1. PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 released (security) · The PHP Group, 2026-10-21
2. Multiples vulnérabilités critiques dans PHP (CERTFR-2026-ALE-014) · CERT-FR (ANSSI), 2026-10-27
3. Critical Vulnerabilities in PHP (Security Advisory 2026-018) · CERT-EU, 2026-10-23
4. Usage statistics of PHP for websites · W3Techs, 2026-10-29
5. Important PHP security update: what website owners need to do · GoDaddy, 2026-10-23
6. Failles critiques PHP : quelles versions mettre à jour et comment protéger vos serveurs · Blog du Modérateur, 2026-10-22