Facebook Linkedin

Publications

Faille PHP2Shell : ce que votre PME doit vérifier cette semaine.

Article 1 sur 5

Mise à jour le 22 octobre 2026, [heure]TechnicitéAccessibleLecture : 7 min

La faille PHP2Shell, en fait deux failles critiques dans PHP, menace les sites Web, les portails clients et certains équipements réseau. Des tentatives d’attaque ont déjà été détectées. Le correctif a été publié le 21 octobre 2026, et votre fournisseur l’a peut-être déjà appliqué. Voici comment le vérifier, quoi faire sinon, et ce que vous risquez.

L’essentiel en 30 secondes

  • Qui est touché : tout site Web, portail ou équipement accessible depuis Internet qui fonctionne avec PHP, comme un site WordPress chez un hébergeur.
  • À faire cette semaine : obtenir de votre fournisseur une confirmation écrite que le correctif est appliqué, et vérifier que la page d’administration de vos pare-feu n’est pas accessible depuis Internet.
  • Ce que vous risquez : un pirate pourrait prendre le contrôle de votre site et voler les données de vos clients.
La question à poser à votre fournisseur

Votre entreprise est-elle concernée?

Tout système accessible depuis Internet qui fonctionne avec PHP est concerné, pas seulement votre site Web.

Probablement oui, si vous avez

  • un site WordPress, WooCommerce, Joomla, Drupal ou PrestaShop chez un hébergeur Web;
  • un portail client, un intranet, un système de réservation ou une plateforme de formation (Moodle) installés sur un serveur;
  • un pare-feu ou un autre équipement réseau dont la page d'administration est accessible depuis Internet. Palo Alto Networks et Netgate (pfSense) ont confirmé que leurs produits sont touchés.

Probablement pas, si

  • votre site est sur une plateforme clés en main, comme Wix, Shopify, Squarespace ou WordPress.com : le fournisseur s'occupe de tout;
  • vous utilisez seulement Microsoft 365, Google Workspace ou un logiciel comptable en ligne.

À vérifier auprès du fournisseur

  • les services en ligne d'un tiers : réservation, formulaires, dons, paie;
  • le Wi-Fi offert à vos clients, par exemple dans un hôtel, un gîte ou un restaurant : demandez quel équipement le gère;
  • votre courriel, s'il est hébergé chez votre hébergeur Web plutôt que chez Microsoft ou Google.

Dans le doute, posez la question à la personne ou à l’entreprise qui gère votre site ou votre réseau.

Que faire cette semaine?

Cinq étapes suffisent dans la plupart des cas, et la deuxième est la plus importante.

  1. Faites la liste de vos systèmes en ligne

    Site Web, boutique, portail client, intranet, équipements réseau, Wi-Fi offert aux clients, services en ligne de tiers. Commencez par ceux qui sont accessibles depuis Internet. Pour chacun, notez qui s'en occupe : vous, une agence, un hébergeur ou un informaticien.

  2. Posez une question précise à ce partenaire

    Demandez une réponse écrite et conservez-la. Les numéros CVE sont les identifiants publics des deux failles : votre fournisseur saura exactement de quoi il s'agit.

    À copier dans votre courriel

    « Le correctif PHP2Shell (CVE-2026-109618 et CVE-2026-109619) est-il appliqué sur nos systèmes? À quelle date? »

  3. Vérifiez la page d'administration de vos pare-feu et routeurs

    Elle ne devrait pas être accessible depuis Internet. Si elle l'est, faites-la fermer aujourd'hui, comme le recommandent Palo Alto Networks et Netgate.

  4. Méfiez-vous du numéro de version

    Certains fournisseurs intègrent le correctif sans changer le numéro : votre site peut afficher PHP 8.3.35 alors qu'il est protégé. À l'inverse, utiliser une version récente de PHP, comme 8.4 ou 8.5, ne suffit pas : c'est la mise à jour corrective qui compte. Fiez-vous à la confirmation écrite de votre fournisseur.

  5. Si vous gérez vous-même votre serveur

    Installez la version corrigée (PHP 8.2.35, 8.3.36, 8.4.27 ou 8.5.12) ou le paquet corrigé de votre distribution Linux. Les précisions sont dans les détails techniques, plus bas.

Les mesures temporaires ne remplacent pas le correctif. Certains hébergeurs, comme Serverprofis en Allemagne, ont désactivé une fonction de PHP en attendant la mise à jour; cette mesure ne ferme qu’un des deux chemins d’attaque. Les sites protégés par Cloudflare bénéficient aussi de règles de filtrage, même avec le forfait gratuit : c’est une protection d’appoint, pas une correction.

Et si la mise à jour pose problème?

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 publie plus de mises à jour pour ces versions, mais certains fournisseurs les corrigent quand même. Sinon, il faut passer à une version récente de PHP, et certaines extensions ou certains thèmes pourraient ne plus fonctionner.

Si votre site ne peut pas être corrigé rapidement, deux options s’offrent à vous, à décider avec votre partenaire :

Mettre le site hors ligne, directement sur le serveur

Surtout s'il recueille des données de clients (formulaires, commandes, comptes). Le Centre national de cybersécurité du Royaume-Uni recommande d'ailleurs d'envisager la mise hors ligne de tout système qui ne peut être ni corrigé ni protégé rapidement.

Attention : une extension « mode maintenance » de WordPress ne protège pas, puisqu'elle fonctionne elle-même avec PHP. Le blocage doit se faire chez l'hébergeur, et protéger seulement l'administration (wp-admin) ne suffit pas.

Mettre PHP à jour, puis régler rapidement les problèmes

C'est acceptable pour un simple site vitrine, à condition d'avoir une sauvegarde récente.

Dans les deux cas, faites une sauvegarde complète avant d’intervenir. Et ne laissez pas un site non corrigé en ligne « en attendant » : des tentatives d’attaque ont déjà été détectées, et les experts s’attendent à une vague d’incidents.

Comprendre en une minute

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. La faille se trouve dans PHP lui-même, sous WordPress. Dans certaines configurations courantes, 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 corrigent : seule la mise à jour de PHP le fait.

Pourquoi c'est sérieux

Les deux failles sont notées 9,2 sur 10 pour leur gravité. Elles peuvent permettre à un pirate de prendre le contrôle d’un serveur Web à distance, sans mot de passe, et des tentatives d’attaque ont déjà été détectées.

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. Le gouvernement du Canada a mis certaines plateformes hors service sur recommandation du Centre canadien pour la cybersécurité, et la NSA américaine suggère de mettre hors ligne tout site PHP non corrigé. À 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.

Quels sont les risques si un système est piraté?

Un pirate qui contrôle l’un de vos systèmes peut s’en servir contre vos clients et contre votre réputation :

  • page d’accueil défigurée, ou redirection vers des sites frauduleux;
  • logiciels malveillants transmis à vos visiteurs, et site mis sur liste noire par Google;
  • vol des données conservées par le site : formulaires, commandes, comptes clients;
  • pourriels envoyés en votre nom, qui empêchent ensuite vos vrais courriels d’arriver à destination.

Un équipement réseau piraté, 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.

Loi 25

Si vous avez des motifs de croire qu'un pirate a pu consulter, copier, utiliser ou détruire des renseignements personnels conservés par votre site, il s'agit d'un incident de confidentialité. Vous devez alors prendre rapidement des mesures pour réduire le risque de préjudice, inscrire l'incident à votre registre et évaluer si ce risque est sérieux. Si c'est le cas, vous devez aviser la Commission d'accès à l'information et les personnes concernées.

Une faille corrigée sans signe d'intrusion n'est pas un incident, mais notez-la dans vos dossiers de sécurité.

Ces renseignements sont généraux et ne remplacent pas un avis juridique (Loi sur la protection des renseignements personnels dans le secteur privé, articles 3.5 à 3.8).

Foire aux questions

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.

Non. La faille se trouve dans PHP, sous WordPress : aucune extension ne peut la corriger. Garder WordPress à jour reste quand même utile : cela complique la tâche d’un pirate qui voudrait s’installer après une intrusion.

Non. Sur ces plateformes clés en main, le fournisseur gère les serveurs et les correctifs.

Demandez à la personne qui le gère si sa page d’administration est accessible depuis Internet. Si oui, faites-la fermer. Au moment d’écrire ces lignes, Palo Alto Networks n’avait pas encore publié de correctif pour ses pare-feu : d’ici là, limiter cet accès est la principale protection. Si vous offrez un Wi-Fi à vos clients, demandez aussi quel équipement le gère.

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.

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.

Pas s’il est hébergé chez Microsoft 365 ou Google Workspace. S’il est chez votre hébergeur Web, avec un webmail comme Roundcube, il fonctionne sur le même serveur que votre site : le correctif de l’hébergeur le protège aussi. Posez-lui la question en même temps.

Détails techniques

TechnicitéAvancéVersions, correctifs rétroportés, mesures temporaires, équipements réseau

Cette section entre dans le détail technique. Vous pouvez aussi la transmettre telle quelle à la personne qui gère vos systèmes.

  • CVE-2026-109618 (GHSA-w8hw-w9fx-j79w), exécution de code à distance par corruption de mémoire lors d’un manque de mémoire (OOM) : si une requête atteint la limite memory_limit au mauvais moment, PHP peut laisser des données internes partiellement initialisées, puis les traiter comme valides. Sur Apache avec mod_php, une requête non authentifiée peut déclencher l’attaque avant l’exécution de tout code applicatif, et l’exécution de code a été démontrée avec les réglages par défaut. Sur PHP-FPM, elle a été confirmée par des chemins passant par le code de l’application.
  • CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp), exécution de code à distance par état global périmé : une erreur fatale au mauvais moment peut laisser un état interne pointer vers la mémoire libérée d’une requête précédente, que la requête suivante traitée par le même processus peut réutiliser (utilisation après libération). L’exécution de code a été démontrée contre une application réelle sous Apache avec mod_php.
  • Gravité : 9,2 sur 10 (CVSS v4.0) pour les deux failles. La note de 10 qui a circulé lors de la fuite du 20 octobre était erronée.
  • Configurations touchées : toute installation de PHP qui répond à des requêtes Web, dont PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Le risque est le plus élevé avec mod_php.
  • Comparaison avec Log4Shell : contrairement à Log4Shell (2021), une bibliothèque enfouie dans de nombreux logiciels, PHP est généralement facile à repérer : dans la plupart des PME, c’est le site Web. Il se cache toutefois aussi dans l’interface d’administration de certains équipements réseau.

Sources : PHP Foundation, Help Net Security.

  • Versions corrigées : PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35, publiées le 21 octobre 2026 (téléchargements officiels).
  • Distributions Linux et fournisseurs de soutien à long terme (LTS) : ils ont reçu les correctifs avant la publication. Vérifiez les paquets mis à jour de votre distribution.
  • PHP 8.1 et antérieures : ces versions ne sont plus prises en charge. L’équipe de sécurité de PHP a exceptionnellement publié des rétroportages minimaux du code source pour PHP 7.4, 8.0 et 8.1, destinés à ceux qui compilent PHP eux-mêmes ou qui n’ont pas de fournisseur LTS. Sinon, passez par un fournisseur LTS ou migrez vers une version prise en charge.
  • Dépôt remirepo : ce dépôt maintenu par un bénévole (rpms.remirepo.net) n’avait pas de mise à jour le jour de la publication. Il était recommandé de passer aux paquets de la distribution ou de compiler PHP.

Source : Help Net Security.

Certains fournisseurs, comme CloudLinux, intègrent le correctif sans changer la version amont. PHP_VERSION et phpinfo() affichent alors l’ancien numéro, par exemple 8.3.35. Vérifiez plutôt la version du paquet et son journal des modifications, qui doit mentionner CVE-2026-109618 et CVE-2026-109619.

Exemples de paquets corrigés cités par Serverprofis : alt-php83 8.3.35-6 et ea-php83 8.3.35-2.cloudlinux.2.

Source : Serverprofis.

En attendant le correctif, certains hébergeurs ont désactivé le suivi de progression des téléversements :

session.upload_progress.enabled = Off

Ce réglage ne ferme qu’un des deux chemins d’attaque. Il ne peut pas être modifié par ini_set(), mais il peut l’être par un fichier .user.ini : ne le réactivez pas avant la mise à jour.

Serverprofis a aussi bloqué, avec une règle ModSecurity, les requêtes POST, PUT et PATCH de type multipart/form-data, ce qui empêche temporairement les téléversements de fichiers par le site. Cloudflare a déployé des règles de pare-feu applicatif (WAF) pour les vecteurs d’attaque connus, offertes à tous ses clients, y compris le forfait gratuit.

Ces mesures réduisent le risque. Seule la mise à jour de PHP corrige la faille.

Sources : Serverprofis, Help Net Security.

  • Palo Alto Networks : PAN-OS (10.2 à 12.2) et Panorama sont touchés, mais seulement l’interface Web d’administration et l’API XML, y compris une interface de données à laquelle un profil de gestion est associé. GlobalProtect et le portail captif ne sont pas touchés. Aucun correctif n’était disponible au moment d’écrire ces lignes. En attendant, limitez l’accès à l’interface d’administration à des adresses internes de confiance et consultez l’avis du fabricant pour les signatures de prévention des menaces.
  • Netgate (pfSense) : touché seulement si l’interface d’administration ou le portail captif est exposé. Par défaut, l’interface n’est accessible que depuis le réseau local. Les paquets corrigés (PHP 8.5.12 pour pfSense Plus 26.07 et 26.03.1 et CE 2.9.0; PHP 8.3.36 pour CE 2.8.1) s’installent en ligne de commande, et non depuis l’interface Web (avis de Netgate).
  • Fortinet et Cisco : les deux fabricants ont publié des avis. Au 22 octobre, aucun produit n’était confirmé comme vulnérable ; 12 produits Fortinet et 31 produits et services Cisco étaient en cours d’examen (Help Net Security).
  • Autres équipements (OPNsense, FreePBX, NAS, outils de supervision) : si leur interface fonctionne avec PHP, considérez-la par prudence comme exposée jusqu’à la confirmation du fabricant. Le centre néerlandais de cybersécurité (NCSC-NL) tient une liste des produits qui dépendent de PHP et pourraient être touchés.
DateÉvénement
2024Les premiers signes de la cause de CVE-2026-109618 sont repérés lors d’un audit externe de PHP, sans moyen d’exploitation concret à l’époque.
11 août 2026La firme Calif et OpenAI signalent indépendamment une exécution de code à distance liée à la même cause.
17 octobre 2026Amazon détecte une tentative d’exploitation sur l’un de ses serveurs pièges, quatre jours avant l’annonce officielle.
20 octobre 2026Les numéros des failles circulent en ligne avec une fausse note de 10 sur 10, sans détail technique. L’équipe de PHP devance la publication du correctif d’une journée. Une vidéo publiée par erreur révèle quelques détails supplémentaires.
21 octobre 2026, 3 h 41Chainguard publie des images corrigées avant la fin de l’embargo.
21 octobre 2026, 10 hPublication de PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12. Palo Alto Networks et Netgate publient leurs avis dans la journée.
22 octobre 2026Searchlight Cyber publie un outil libre de détection.

Heures du Québec. Sources : PHP Foundation, Help Net Security.

Searchlight Cyber a publié php2shell-scanner, un outil libre qui vérifie si un hôte est exposé aux deux failles. Utilisez-le seulement sur des systèmes dont vous êtes responsable.

Si un système n’a pas pu être corrigé rapidement, cherchez des traces d’intrusion et des portes dérobées avant ou pendant la mise à jour, comme le recommande le NCSC britannique.

Méfiez-vous des prétendus codes d’exploitation qui circulent en ligne : leur fiabilité n’est pas vérifiée, et ce type de code contient parfois des logiciels malveillants.

Dans ce dossier

  1. Faille PHP2Shell : ce que votre PME doit vérifier cette semaine

    TechnicitéAccessibleLecture : 7 minVous lisez cet article

  2. PHP, hébergeur, pare-feu : qui est responsable de quoi?

    TechnicitéAccessibleLecture : 4 minÀ paraître

  3. Correctifs, mesures temporaires et vérifications

    TechnicitéAvancéLecture : 8 minÀ paraître

  4. Pare-feu et Wi-Fi invité : fermer l'accès d'administration

    TechnicitéIntermédiaireLecture : 5 minÀ paraître

  5. Après l'alerte : tenir l'inventaire de vos systèmes en ligne

    TechnicitéAccessibleLecture : 5 minÀ paraître

← Page du dossier

Sources et mises à jour

La situation évolue rapidement : cet article sera mis à jour au besoin.

Historique des mises à jour :

  • 22 octobre 2026, [heure] : publication.
Catégories
Dernières publications