PHP a publié le mercredi 21 octobre 2026 les versions 8.2.35, 8.3.36, 8.4.27 et 8.5.12, qui corrigent deux failles critiques permettant d’exécuter du code sur le serveur sans identifiant. Une boutique PrestaShop tourne sur PHP : si sa version de PHP est touchée par la faille, la boutique l’est aussi, quelle que soit sa version de PrestaShop. Notez votre version de PHP, demandez à votre hébergeur quand il appliquera le correctif et faites une sauvegarde.
Officiel depuis le 21/10 : deux failles notées 9.2 sur 10 (CVSS v4.0), qui permettent d’exécuter du code à distance sans identifiant. Corrigées dans PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12.
Versions plus anciennes : PHP ne publie pas de correctif pour elles ; le CERT-EU les considère touchées depuis PHP 5.
PrestaShop 1.6, 1.7 et 8 tournent, dans leur plage officielle, sur des versions de PHP que PHP ne corrige plus : le correctif du 21 octobre ne les couvre pas.
Bonne nouvelle toutefois : les paquets PHP de Debian et d’Ubuntu (deb.sury.org), sur lesquels s’appuient beaucoup de serveurs, prévoient un correctif rétroporté y compris pour ces versions en fin de vie. Il faut alors que votre hébergeur l’installe dès qu’il est disponible.
À faire maintenant : quatre gestes, dont une sauvegarde à garder à part.
Vous ne savez pas qui met votre PHP à jour, ou votre boutique est en 1.6, 1.7 ou 8 ? Écrivez-nous ou appelez le 09 72 03 59 17, 7j/7, de 8 h à 22 h.
Ce que PHP a annoncé le 20 octobre
L’équipe sécurité de PHP a prévenu le 20 octobre, sur php.net et sur le forum de la PHP Foundation : une version de sécurité sort le mercredi 21 octobre 2026 à 14:00 UTC, soit 16 h à Paris. Elle corrige deux vulnérabilités, toutes deux notées 9.2 sur l’échelle CVSS v4.0, le niveau « critique ».
Rien d’autre n’est public. L’annonce le dit elle-même : les détails, les versions touchées et les versions corrigées seront publiés avec le correctif. Elle garde aussi une porte ouverte : publier plus tôt si les détails d’une des failles fuitent, ou si une exploitation est repérée.
Mise à jour du 21 octobre : PHP a publié les versions corrigées et deux avis de sécurité (CVE-2026-109618 et CVE-2026-109619). Les deux failles permettent d’exécuter du code sur le serveur sans identifiant, avec les droits du site. La première s’appuie notamment sur une requête d’envoi de formulaire qui épuise la mémoire allouée à PHP ; la seconde, sur des données qu’une requête laisse derrière elle et qu’une requête suivante réutilise. Sont touchées toutes les versions des branches 8.2 à 8.5 antérieures à 8.2.35, 8.3.36, 8.4.27 et 8.5.12. PHP prévient : seule la mise à jour corrige complètement, les réglages de contournement réduisent le risque sans le supprimer.
Ce qui circule déjà, sans confirmation de PHP
Cette partie a été écrite avant la publication du 21 octobre. Les avis officiels confirment l’exécution de code à distance ; PHP ne détaille les versions touchées que pour les branches qu’il suit encore.
Depuis la veille, des sociétés de sécurité en disent plus que PHP. Sansec, spécialiste de la sécurité des boutiques en ligne, et Threat Landscape rapportent :
- deux identifiants réservés, CVE-2026-109618 et CVE-2026-109619, encore sans description publique ;
- des failles d’exécution de code à distance : un attaquant ferait exécuter son propre code au serveur ;
- toutes les versions depuis PHP 5.4 seraient touchées, d’après la capture d’écran d’un outil d’attaque qui a fuité ;
- une fuite partie d’un message publié puis retiré sur Hacker News, le 20 octobre.
Le CERT-EU, l’équipe de réponse aux incidents des institutions européennes, va dans le même sens dans son avis 2026-018 du 20 octobre au soir. Il cite les deux mêmes identifiants, une exécution de code à distance possible sans identifiant ni mot de passe, et « toutes les versions de PHP depuis PHP 5 ». Il recommande de se tenir prêt à corriger tout de suite, et d’envisager d’isoler d’internet les applications exposées en attendant le correctif.
Sansec s’attend à des attaques en masse dans le quart d’heure qui suivra la publication. Deux éléments nouveaux le 21 octobre au matin. D’abord, la société watchTowr indique avoir reproduit en laboratoire l’une des deux failles (CVE-2026-109618) : l’exécution de code à distance est confirmée par une source indépendante, avant même la publication officielle de PHP.
Ensuite, Patchstack signale de premières tentatives d’attaque remontées par des hébergeurs partenaires, et rapporte que Cloudflare en voit aussi. À prendre avec prudence : aucune preuve technique n’est publiée, et watchTowr, qui a pourtant reproduit la faille, n’a pas constaté d’exploitation réussie à ce stade ; l’activité observée s’appuierait sur l’exploit incomplet qui a fuité. Quoi qu’il en soit, dès la publication, une boutique dont le PHP n’est pas corrigé devient une cible, que son PrestaShop soit à jour ou non. Le correctif PHP reste la seule vraie parade.
Votre boutique PrestaShop est-elle concernée ?
Chaque page de votre boutique, du catalogue au paiement, est fabriquée par PHP. La faille se trouve dans PHP, pas dans PrestaShop : aucun module, aucune mise à jour de PrestaShop ne la referme. Seule une nouvelle version de PHP, installée sur le serveur, la corrige.
Encore faut-il que votre version de PHP reçoive ce correctif. PHP ne corrige aujourd’hui que les branches 8.2, 8.3, 8.4 et 8.5 (calendrier officiel). Or chaque version de PrestaShop n’accepte officiellement qu’une plage de PHP :
| Version de PrestaShop | PHP accepté officiellement | Encore corrigé par PHP ? |
|---|---|---|
| 1.6.1 | 5.2 à 7.1 | Non |
| 1.7.8 | 7.1.3 à 7.4 | Non |
| 8.0 à 8.2 | 7.2.5 à 8.1 | Non |
| 9.0 | 8.1 à 8.4 | Oui en 8.2, 8.3, 8.4 ; non en 8.1 |
| 9.1 et 9.2 | 8.1 à 8.5 | Oui en 8.2 à 8.5 ; non en 8.1 |
Une boutique en 1.6, 1.7 ou 8 qui reste dans sa plage officielle tourne sur un PHP en fin de vie : le correctif du 21 octobre ne lui est pas destiné. Quand une boutique 1.7 arrive chez nous, elle tourne presque toujours en PHP 7.4, sans correctif depuis novembre 2022. Le détail par version, et ce qui casse quand on change de PHP, est dans notre article PrestaShop version PHP.
Si votre boutique est dans ce cas, demandez à votre hébergeur s’il maintient lui-même votre version de PHP et s’il y reportera ce correctif.
Quatre gestes à faire maintenant
- Notez votre version de PHP. Dans le back-office, Paramètres avancés > Informations, ligne « Version de PHP ». Sans back-office, le panneau de l’hébergeur l’affiche (où la trouver).
- Sachez qui met PHP à jour. Sur un hébergement mutualisé, c’est l’hébergeur. Sur un serveur dédié ou un VPS, c’est vous ou votre prestataire. Écrivez-lui dès maintenant : « Appliquerez-vous la version de sécurité PHP du 21 octobre, quand, et pour ma version de PHP ? »
- Faites une sauvegarde des fichiers et de la base de données dès maintenant, et gardez-en une copie hors du serveur, à part des sauvegardes automatiques qui pourraient l’écraser.
- Prévoyez quelqu’un pour appliquer la mise à jour dès qu’elle est disponible, ou vérifier qu’elle est passée, puis tester la boutique.
Donnez-nous votre version de PrestaShop et votre hébergeur : nous vous disons si le correctif vous concerne et qui doit l’appliquer. Si une intervention est nécessaire, elle est dès 150 € HT, prix fixe validé avant toute intervention.
Mettre PHP à jour sans casser la boutique
Si votre PHP est en 8.2, 8.3, 8.4 ou 8.5, la mise à jour reste dans la même branche : de 8.3.35 à 8.3.36, par exemple. Les versions à atteindre : 8.2.35, 8.3.36, 8.4.27 ou 8.5.12. Ces versions ne contiennent que des corrections de bugs et de sécurité ; en règle générale, une boutique PrestaShop qui tourne aujourd’hui sur la branche continue de tourner. Testez-la quand même. Une fois la mise à jour faite, vérifiez dans Paramètres avancés > Informations que le numéro a changé, puis passez une commande test : accueil, fiche produit, panier, paiement, connexion au back-office.
Si votre PHP est en 8.1 ou plus ancien, ne changez pas de branche dans la précipitation. Faire passer une 1.6 ou une 1.7 en PHP 8 fait le plus souvent tomber la boutique en erreur 500. Il faut d’abord la réponse de l’hébergeur sur son propre correctif. En attendant, il peut couper le suivi des envois de PHP (session.upload_progress), comme PHP le recommande : cela ferme l’un des chemins d’attaque, pas tous. Ensuite, la sortie durable reste la migration vers PrestaShop 9, qui accepte les versions de PHP encore corrigées.
Dans les jours qui suivent, surveillez les signes d’intrusion : fichiers PHP inconnus à la racine ou dans les dossiers d’images, compte administrateur que personne n’a créé, page de paiement modifiée, redirections vers d’autres sites. Si vous en voyez un, appelez-nous au 09 72 03 59 17 (7j/7, de 8 h à 22 h) et suivez les étapes de notre page boutique PrestaShop piratée avant de toucher à quoi que ce soit.
Article mis à jour le 21 octobre après la publication de PHP. Nous le compléterons quand les correctifs rétroportés pour les versions en fin de vie seront disponibles.
Questions fréquentes sur la faille PHP et PrestaShop
Ma boutique PrestaShop est-elle touchée par la faille PHP ?
Oui si son PHP est en 8.2, 8.3, 8.4 ou 8.5 et antérieur à 8.2.35, 8.3.36, 8.4.27 ou 8.5.12, quelle que soit sa version de PrestaShop. Pour les versions plus anciennes, PHP ne publie pas de correctif ; le CERT-EU les considère touchées depuis PHP 5. Il faut alors un correctif rétroporté par l’hébergeur ou une migration.
PrestaShop va-t-il publier une mise à jour ?
Pas pour cette faille. Le correctif est une nouvelle version de PHP, installée sur le serveur ; mettre à jour PrestaShop ou un module ne referme pas la faille.
Mon hébergeur fera-t-il la mise à jour tout seul ?
Sur un hébergement mutualisé, c’est en général lui qui met PHP à jour, à son rythme. Sur un serveur dédié ou un VPS, c’est à vous ou à votre prestataire. Dans les deux cas, demandez-lui une date, et vérifiez ensuite le numéro de version dans Paramètres avancés > Informations.
Ma boutique est en PHP 7.4 : que faire ?
PHP 7.4 ne reçoit plus de correctifs de l’équipe PHP depuis le 28/11/2022. Pour cette faille, les dépôts PHP de Debian et d’Ubuntu (deb.sury.org), sur lesquels s’appuient beaucoup de serveurs, prévoient toutefois un correctif rétroporté sur la 7.4 : demandez à votre hébergeur s’il s’en sert et quand il l’appliquera. Cela colmate la faille sans changer de version. Ne passez pas en PHP 8 sans préparation : une 1.6 ou une 1.7 n’y démarre généralement pas. Pour une sortie durable, seule une migration vers PrestaShop 9 règle le problème.
Sources : php.net, annonce du 20/10/2026 ; avis CVE-2026-109618 et CVE-2026-109619 du 21/10/2026 ; PHP Foundation ; versions de PHP suivies ; Sansec ; Threat Landscape ; watchTowr ; Patchstack ; CERT-EU, avis 2026-018.
Faire vérifier le PHP de votre boutique
Indiquez dans le message votre version de PrestaShop, votre version de PHP si vous l’avez, et votre hébergeur. Nous répondons en moins d’une heure, 7j/7, de 8 h à 22 h, par formulaire comme au 09 72 03 59 17. Une intervention coûte dès 150 € HT, prix fixe validé avant toute intervention ; ces 150 € sont déduits si vous passez ensuite à la maintenance PrestaShop. Avec l’hébergement PrestaShop, en option de la maintenance, c’est nous qui réglons la version de PHP et appliquons ses mises à jour.
