Faille PHP : sécurisez votre boutique en ligne avant le 31 décembre

Le mercredi 21 octobre 2026, le projet PHP a publié quatre versions corrigées d’une faille critique qui touche directement votre boutique en ligne. Mais le correctif n’a pas clos le sujet : la plupart des dirigeants ne savent pas encore ce que leur hébergeur a réellement déployé, et une échéance plus discrète les attend, la fin de vie de PHP 8.2 le 31 décembre 2026.

Le correctif est publié, la mise à jour rarement terminée

Les versions 8.2.35, 8.3.36, 8.4.27 et 8.5.12, le correctif PHP2Shell, corrigent deux failles critiques, CVE-2026-109618 et CVE-2026-109619. Toutes deux permettent une exécution de code à distance par un attaquant non authentifié, avec un score CVSS v4.0 de 9,2. Le code peut s’exécuter avant que la moindre ligne de votre boutique ne soit appelée.

La faille est dans le moteur PHP, l’interpréteur qui fait tourner votre site. Mettre à jour Prestashop, ses modules ou votre thème n’y change rien : la correction se fait sur le serveur, chez votre hébergeur. Cloudflare l’a rappelé dans les mêmes termes, seule la mise à jour du moteur corrige ces deux failles.

Nuance importante : le projet PHP ne publie plus de mise à jour pour les branches 8.1 et antérieures. Certaines distributions et certains hébergeurs peuvent rétroporter un correctif dans un paquet existant, sans garantie : si votre boutique tourne sur ces versions, attendez-vous à devoir décider d’une migration.

Votre hébergeur a-t-il vraiment déployé le correctif ?

Sur un hébergement mutualisé, l’hébergeur installe PHP, vous n’avez pas la main dessus. La vérification vous revient, et elle est moins évidente qu’elle n’en paraît. La commande php -v interrogée en ligne de commande affiche la version de l’interpréteur disponible sur le serveur, pas nécessairement celle qui traite les requêtes de votre boutique.

La seconde difficulté vient du redémarrage. Installer le paquet ne remplace pas le code déjà chargé en mémoire. Tant qu’un processus vulnérable tourne, il continue de traiter des requêtes avec l’ancien code. Il faut donc redémarrer PHP-FPM ou le serveur web, mais aussi renouveler les processus de longue durée qui gardent l’ancien code en mémoire.

Le cas le plus trompeur est celui de mod_php : une seule requête anonyme peut déclencher le chemin vulnérable avant l’exécution du moindre code applicatif.

Une distribution peut aussi rétroporter un correctif dans un paquet dont le numéro paraît ancien. Le numéro affiché ne suffit donc pas à conclure : il faut la confirmation écrite du fournisseur sur les deux identifiants de faille.

La vraie échéance est le 31 décembre 2026

Voici ce que la plupart des communications techniques ont passé sous silence. Les versions corrigées d’aujourd’hui ne sont qu’un répit. Le calendrier du projet PHP place la fin du support de sécurité de PHP 8.2 au 31 décembre 2026. Les branches suivantes ont suivi le même schéma de support jusqu’à présent.

Concrètement, un marchand sur PHP 8.2 a aujourd’hui un correctif qui expire dans deux mois. Un marchand sur PHP 8.1 dépend d’un éventuel rétroportage par son hébergeur. La question n’est donc plus « ma boutique est-elle sécurisée », mais « quelle version de PHP je vise, et à quel coût ». C’est un arbitrage de budget et de calendrier, pas une tâche d’administrateur.

Prestashop 9 est la version majeure actuelle, et son évolution a accompagné la montée des versions de PHP. Notre article sur Prestashop 9 : ce qui change concrètement pour votre boutique détaille cette trajectoire si vous situez votre plateforme avant de décider.

Trois vérifications à mener cette semaine sur votre boutique

La séquence n’a rien de technique pour vous, elle demande trois preuves écrites et un test.

1. Demandez la version réellement servie. Envoyez à votre hébergeur une demande datée citing les deux identifiants de faille et le numéro de version attendu pour votre branche. Conservez la réponse : c’est votre preuve, et elle vous servira si la question vous est reposée plus tard.
2. Faites confirmer le redémarrage. Demandez explicitement que les workers de PHP-FPM et le serveur web aient redémarré, et non seulement que le paquet soit installé. C’est le point le plus souvent omis.
3. Testez le parcours d’achat. Après intervention, vérifiez la connexion, les formulaires, la commande et le paiement. Une version de correctif ne change ni la syntaxe ni les fonctions, mais un redémarrage mal mené casse souvent un module de paiement ou d’expédition.

Cette séquence rejoint notre maintenance Prestashop : ce que contient le suivi mensuel : le contrôle de la version PHP y fait partie des vérifications systématiques, pas des réactions d’urgence.

Les limites que les atténuations ne couvrent pas

Le projet PHP a publié des mesures provisoires. Elles réduisent certains chemins d’attaque, aucune ne referme la faille. Le réglage session.upload_progress.enabled=0 bloque les chemins liés à la session pour CVE-2026-109619, sans couvrir toutes les variantes. Pour CVE-2026-109618, PHP recommande memory_limit=-1, un post_max_size bas et des limites de taille de requête au niveau du serveur web ou du proxy.

Nous considérons ces mesures comme un filet de sécurité le temps de la mise à jour, jamais comme une alternative : seule la mise à jour ferme la faille.

Reste un point que les sources publiques consultées n’établissent pas. Selon The Register, watchTowr observait des tentatives d’exploitation dès le jour de la publication, sans qu’aucune n’ait encore réussi au 22 octobre 2026. Cela justifie de relire les journaux serveur plutôt que de conclure que tout va bien. Cherchez les requêtes anonymes inhabituelles, les fichiers PHP sollicités à des heures anormales et les adresses réseau hors de votre géographie habituelle.

Enfin, ces mesures techniques ne remplacent pas un audit. Si votre hébergement est critique pour votre activité, faites-le vérifier par un professionnel.

Que retenir, quelle décision prendre ?

Si votre boutique tourne sur PHP 8.2, 8.3, 8.4 ou 8.5, vous avez un correctif disponible. La priorité est d’obtenir de votre hébergeur la preuve écrite du déploiement et du redémarrage, puis de tester le tunnel de commande cette semaine.

Si votre boutique tourne sur PHP 8.1 ou une version antérieure, le projet PHP n’y publie plus rien et un éventuel correctif dépend du rétroportage de votre hébergeur, que rien ne garantit. Préparez la migration, elle est le seul point stable.

Si votre hébergeur ne donne pas de réponse écrite, ce silence est en soi une information. Un hébergement mutualisé sans traçabilité sur ses versions est un risque pour une boutique qui encaisse des paiements.

---

Vous souhaitez savoir où votre boutique en ligne en est réellement sur sa version de PHP et sur ses correctifs de sécurité ? Consultez notre page création de boutique Prestashop pour voir ce que recouvre un accompagnement sur la plateforme, ou contactez-nous pour en parler.

Questions complémentaires sur la faille PHP

Les atténuations remplacent-elles la mise à jour de PHP ?

Non. Le projet PHP est explicite, le correctif est la seule réparation complète. Les mesures provisoires réduisent certains vecteurs d’attaque, le réglage lié à la session ne couvre pas toutes les variantes de CVE-2026-109619 et la limite mémoire n’éponge pas tous les échecs d’allocation. Les conserver ne dispense pas de mettre à jour, cela limite seulement la fenêtre d’exposition.

Mon site est-il compromis, comment le vérifier ?

Sans indice concret, la lecture des journaux serveur reste le premier réflexe. Observez les requêtes anonymes inhabituelles, les fichiers PHP sollicités hors de vos habitudes et les adresses réseau qui n’appartiennent pas à votre clientèle. Auditez aussi les fichiers modifiés depuis la publication du correctif, le 21 octobre 2026. Cette relecture ne remplace pas un audit professionnel, mais elle vous donne une indication immédiate.