La faille PHP2Shell, en fait deux failles critiques dans PHP, menace les sites Web, les portails clients et certains équipements réseau, et elle est déjà exploitée par des pirates. Le correctif est sorti le 21 octobre 2026, et vos fournisseurs l’ont peut-être déjà appliqué. Voici comment le vérifier, quoi faire sinon, et ce que vous risquez.
PHP2Shell désigne deux failles critiques dans PHP (CVE-2026-109618 et CVE-2026-109619). Elles permettent à un pirate humain ou automatisé de prendre le contrôle d’un serveur Web à distance, sans mot de passe (source : Help Net Security).
PHP, c’est quoi ? C’est le moteur qui travaille en coulisses de votre site : chaque fois qu’un visiteur ouvre une page, PHP la construit. WordPress, WooCommerce, Joomla, Drupal, PrestaShop et Moodle fonctionnent tous avec PHP.
Une image pour comprendre. Votre site est un appartement, et PHP est la serrure de la porte de l’immeuble. Votre appartement peut être impeccable : extensions à jour, mots de passe solides. Mais si la serrure de l’immeuble a un défaut, quiconque connaît le truc peut entrer. Et c’est généralement le propriétaire de l’immeuble, votre hébergeur, qui change la serrure.
Pourquoi vos extensions de sécurité ne suffisent pas. L’attaque se déclenche avant même que WordPress démarre. Ni une extension de sécurité ni une mise à jour de WordPress ne la bloquent : seule la mise à jour de PHP le fait (Serverprofis).
| Date | Événement |
|---|---|
| 21 octobre 2026 | Correctifs publiés : PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12 (Help Net Security) |
| 20 octobre 2026 | Les détails des failles sont rendus publics avant la date prévue (Serverprofis) |
| 17 octobre 2026 | Amazon détecte une première tentative d’exploitation, quatre jours avant l’annonce publique (Help Net Security) |
Il se cache toutefois aussi dans certains équipements. Palo Alto Networks a confirmé que tous ses pare-feu sous PAN-OS sont touchés, et Fortinet comme Cisco vérifient leurs produits (Help Net Security).
Au Québec, de grandes organisations ont préféré fermer. Le 21 octobre, les sites de la STM, de la SAQ, de la SAAQ, de Statistique Canada et de centres de services scolaires, y compris leur plateforme Moodle, étaient inaccessibles en tout ou en partie, par précaution (Narcity). Le gouvernement du Canada a mis certaines plateformes hors service sur recommandation du Centre canadien pour la cybersécurité, et la NSA américaine recommande de mettre hors ligne tout site PHP non corrigé (Noovo Info). À noter : l’interruption de l’Espace client d’Hydro-Québec, le même jour, n’était pas liée à PHP selon la société d’État (Narcity).
Tout système accessible depuis Internet qui fonctionne avec PHP est concerné, pas seulement votre site Web. Si vous avez un site WordPress chez un hébergeur, la réponse est probablement oui.
Probablement oui si vous avez :
Probablement pas si :
À vérifier auprès du fournisseur : les services en ligne d’un tiers que vous utilisez, comme une plateforme de réservation, de formulaires, de dons ou de paie. Demandez-lui s’il utilise PHP et s’il a appliqué le correctif.
Dans le doute, posez la question à la personne ou à l’entreprise qui gère votre site ou votre réseau.
Quatre étapes suffisent dans la plupart des cas, et la deuxième est la plus importante.
Les mesures temporaires ne remplacent pas le correctif. Beaucoup d’hébergeurs ont désactivé une fonction de PHP en attendant la mise à jour. Cette mesure ne ferme qu’un des deux chemins d’attaque (Serverprofis). De même, les sites protégés par Cloudflare bénéficient de règles de filtrage, même avec le forfait gratuit (Help Net Security) : c’est une protection d’appoint, pas une correction.
Rarement : dans la plupart des cas, le correctif est une mise à jour mineure, souvent appliquée par l’hébergeur sans que vous le remarquiez.
Le vrai risque concerne les sites qui fonctionnent encore avec PHP 8.1 ou une version plus ancienne. L’équipe de PHP ne les corrige plus, mais certains fournisseurs le font quand même (Help Net Security). Sinon, il faut passer à une version récente de PHP, et certaines extensions ou certains thèmes pourraient ne pas suivre.
Si votre site ne peut pas être corrigé rapidement, deux options s’offrent à vous, à décider avec votre partenaire :
Dans les deux cas, faites une sauvegarde complète avant d’intervenir. Et ne laissez pas un site non corrigé en ligne « en attendant » : la faille est activement exploitée.
Un pirate qui contrôle l’un de vos systèmes peut s’en servir contre vos clients et contre votre réputation :
Un équipement réseau compromis, comme un pare-feu, est encore plus grave : il peut ouvrir l’accès à tout votre réseau interne.
Signes à surveiller dans les prochains jours : des comptes administrateurs inconnus, des pages ou des fichiers que vous n’avez pas créés, des alertes de votre extension de sécurité ou de votre hébergeur, un avertissement de Google ou des visiteurs qui signalent des redirections étranges.
Et la Loi 25 ? Si votre site contient des renseignements personnels et que vous soupçonnez une intrusion, c’est un incident de confidentialité. Vous devez l’inscrire à votre registre des incidents et évaluer le risque de préjudice pour les personnes touchées. Si ce risque est sérieux, vous devez aviser la Commission d’accès à l’information et les personnes concernées. Une vulnérabilité corrigée sans signe d’intrusion n’est pas un incident, mais il vaut la peine de la noter dans vos dossiers de sécurité.
Mon site affiche une ancienne version de PHP. Est-il vulnérable ? Pas forcément. Certains hébergeurs intègrent le correctif sans changer le numéro de version. Seule la confirmation écrite de votre fournisseur permet de trancher.
Mes extensions WordPress sont à jour. Suis-je protégé ? Non. La faille se trouve dans PHP, sous WordPress, et l’attaque se déclenche avant que WordPress démarre. Garder WordPress à jour reste quand même utile : cela complique la tâche d’un pirate qui voudrait s’installer après une intrusion.
Mon site est sur Wix, Shopify ou Squarespace. Dois-je faire quelque chose ? Non. Sur ces plateformes clés en main, le fournisseur gère les serveurs et les correctifs.
Faut-il mettre mes systèmes hors ligne ? Seulement ceux qui ne peuvent pas être corrigés rapidement, surtout s’ils recueillent des données de clients. De grandes organisations, comme la STM et la SAQ, l’ont fait par précaution. Dans ce cas, la fermeture doit se faire chez l’hébergeur : une extension de maintenance WordPress ne protège pas.
Comment savoir si mon site a été piraté ? Cherchez des comptes administrateurs inconnus, des fichiers que vous n’avez pas créés ou des redirections étranges. Demandez aussi à votre hébergeur s’il a détecté une activité suspecte sur votre compte.
Mon courriel est-il touché ? Non, s’il est hébergé chez Microsoft 365 ou Google Workspace. La faille vise les serveurs qui exécutent PHP, comme ceux des sites Web.
La situation évolue rapidement : cet article pourrait être mis à jour.
Aller au contenu