Faille PHP2Shell du 21 octobre : le site de votre entreprise est-il vraiment corrigé ?

Le 21 octobre 2026, PHP a corrigé en urgence deux failles critiques, surnommées « PHP2Shell ». PHP est le langage qui fait fonctionner WordPress, PrestaShop, Joomla et bien d'autres sites internet. Ces failles permettent à un pirate de faire exécuter ses propres programmes par le serveur, à distance et sans aucun identifiant. Cybermalveillance.gouv.fr a lancé une alerte, le CERT-FR (le centre d'alerte de l'ANSSI) a constaté des tentatives d'attaque, et le portail Amelipro des professionnels de santé a été fermé par précaution. Si votre entreprise ou votre cabinet a un site, la question n'est pas « suis-je visé ? », mais « mon site est-il corrigé ? ». Voici comment le savoir, qui doit agir, quoi demander par écrit et ce qu'il ne faut surtout pas faire.

Ce qui s'est passé depuis le 20 octobre

• 20 octobre : PHP annonce deux failles critiques, notées 9,2 sur 10 sur l'échelle de gravité CVSS.
• 21 octobre, 16 h : sortie des versions corrigées 8.2.35, 8.3.36, 8.4.27 et 8.5.12. Les failles (CVE-2026-109618 et CVE-2026-109619) menacent toutes les installations de PHP qui répondent à des requêtes web, précise PHP.
• 22 octobre : l'« AlerteCyber » de Cybermalveillance.gouv.fr prévient que des cybercriminels pourraient très prochainement mener des attaques massives, et juge ces failles « particulièrement critiques pour les sites Internet transactionnels ».
• 23 octobre : PHP signale une troisième faille (CVE-2026-115560), exploitable seulement dans une configuration peu probable, et conseille de désactiver, jusqu'à sa prochaine mise à jour régulière, le suivi de la progression des téléversements.
• 26 octobre : le CERT-FR constate des tentatives d'exploitation visant certaines configurations de PHP.

Côté santé, l'Assurance maladie a fermé « à titre conservatoire » le portail Amelipro du 21 au 27 octobre, selon Egora, qui précisait le 23 octobre qu'elle avait directement mis en cause PHP ; sa page de maintenance évoquait d'ailleurs les « composants en langage PHP ».

Votre site est-il concerné ?

Oui, s'il fonctionne avec PHP, quelle que soit sa taille. Les indices :

• Il a été fait avec WordPress, PrestaShop ou Joomla : d'après leurs exigences techniques, ces logiciels fonctionnent avec PHP.
• Votre espace d'hébergement permet de choisir la version de PHP, ou des adresses de votre site se terminent par « .php ».
• Votre site est sur une plateforme en ligne, sans hébergement à gérer : ses serveurs sont l'affaire de la plateforme.
• Dans le doute, demandez à la personne ou à l'agence qui a réalisé votre site.

« Mon site est trop petit pour intéresser un pirate » ? Erreur. Aucun compte n'est nécessaire : il suffit d'atteindre une page en PHP, rappelle CloudLinux, éditeur d'un système pour serveurs d'hébergement, qui signale un outil d'attaque public utilisé pour passer Internet au crible. Dans la configuration la plus exposée, l'attaque peut se déclencher avant même que le code du site ne s'exécute, précise PHP : un site vitrine sans formulaire est concerné, lui aussi.

Qui doit agir ? Tout dépend de votre hébergement

• Hébergement mutualisé (un serveur partagé, géré par l'hébergeur) : c'est l'hébergeur qui installe la version corrigée de PHP. À vous de vérifier, et de choisir dans votre espace client une version encore suivie.
• Serveur privé virtuel (VPS) ou serveur dédié : c'est à vous, ou au prestataire qui l'administre. Les distributions Linux ont reçu les correctifs à l'avance, indique PHP : installez les mises à jour du système, puis redémarrez PHP ou le serveur web (pour chaque version de PHP installée, ajoute CloudLinux).
• Site réalisé par une agence ou un webmaster : si votre contrat comprend le suivi, c'est à lui de vérifier et de vous le confirmer. Sinon, ne supposez pas que quelqu'un s'en est occupé.
• PHP 8.1 ou plus ancien : PHP n'en publie plus de version corrigée. Certains éditeurs le font encore (CloudLinux, jusqu'à PHP 5.2), mais le CERT-FR recommande d'isoler ces installations, puis de passer à une version maintenue. Quant à PHP 8.2, ses correctifs de sécurité s'arrêtent le 31 décembre 2026. Préparez la migration avec votre prestataire, en testant le site avant la bascule : WordPress recommande PHP 8.3 ou plus récent.

Le conseil du technicien : ne vous fiez pas au seul numéro de version

Sur beaucoup de serveurs, le correctif est « rétroporté » : l'éditeur du système ou l'hébergeur l'ajoute à la version déjà installée, sans changer son numéro. Cette pratique est courante, explique Red Hat : le numéro seul ne dit pas si un logiciel est vulnérable. CloudLinux le confirme pour ces failles : la plupart de ses premières versions corrigées affichaient un numéro inférieur à celui de PHP (8.4.26 au lieu de 8.4.27, par exemple). Un outil d'analyse en ligne qui compare seulement les numéros peut donc signaler à tort un site corrigé.

Le bon réflexe : ouvrir la page d'informations de PHP (« phpinfo ») si votre espace d'hébergement la propose, ou la demander à votre prestataire (une page créée pour l'occasion doit ensuite être supprimée : elle en dit trop sur le serveur). Elle montre la version réellement en service :

1. « PHP Version », tout en haut : avec 8.2.35, 8.3.36, 8.4.27, 8.5.12 ou plus récent dans la même série, le correctif est là.
2. « Build Date » : la date de compilation (de fabrication) de ce PHP, écrite à l'anglaise (« Oct 21 2026 » pour le 21 octobre 2026). Un numéro plus ancien avec une date du 21 octobre 2026 ou plus récente : bon signe, le correctif a probablement été rétroporté. Avec une date antérieure à l'alerte, interrogez votre hébergeur sans attendre.
3. « session.upload_progress.enabled » (cherchez-le avec Ctrl+F) : l'option de suivi de la progression des téléversements, activée par défaut. « Off » veut dire désactivée.

Désactiver cette option ne remplace pas la mise à jour : cela bloque seulement certaines attaques contre l'une des deux failles. Mais PHP conseille de la laisser désactivée, même après la mise à jour, jusqu'à sa prochaine version régulière, et juge prudent de la couper durablement si le site n'en a pas besoin : la fonction est peu utilisée et de plus en plus examinée par les attaquants. Demandez ce réglage à votre hébergeur ou à votre prestataire.

Ces vérifications donnent un indice, pas une preuve : seul l'hébergeur peut confirmer la correction. Pour notre part, le 23 octobre, nous avons vérifié un par un les 11 sites en PHP dont nous nous occupons : partout, le correctif avait été installé par l'hébergeur (date de compilation du 21 octobre), et l'option de suivi des téléversements était désactivée. Sur trois d'entre eux, chaque fichier en ligne a été comparé à sa version d'origine : aucune trace d'intrusion.

Ce qu'il faut demander par écrit

Un e-mail à votre hébergeur ou à votre prestataire suffit ; gardez sa réponse. Vous pouvez reprendre ces questions :

1. Quelle version de PHP fait fonctionner mon site, et intègre-t-elle la correction des failles CVE-2026-109618 et CVE-2026-109619 publiée le 21 octobre 2026 ? Depuis quand ?
2. L'option « session.upload_progress.enabled » est-elle désactivée dans la configuration du serveur, comme le conseille PHP ?
3. Avez-vous constaté des tentatives d'attaque ou des fichiers suspects sur mon hébergement depuis le 21 octobre ?
4. De quand date ma dernière sauvegarde, et jusqu'à quelle date pourriez-vous restaurer mon site ?
5. Si mon site utilise PHP 8.2 ou une version plus ancienne : quand passer à une version suivie, et qui teste le site avant ?

Demandez aussi la mise à jour du site lui-même (WordPress et ses extensions, par exemple) : selon Cybermalveillance.gouv.fr, une grande majorité des attaques de sites exploitent des failles dont les correctifs « ne sont pas toujours appliqués en temps utiles ».

Ce qu'il ne faut surtout pas faire

• Tout effacer et réinstaller dans la panique : en cas d'intrusion, vous détruiriez les traces. Cybermalveillance.gouv.fr conseille de conserver les preuves (journaux, copie complète de la machine touchée).
• Couper le site sans prévenir : une mise hors ligne se décide avec l'hébergeur ou le prestataire (le CERT-FR recommande d'isoler les installations qui ne sont plus corrigées, le temps de migrer) et s'annonce à vos clients, comme l'a fait l'Assurance maladie pour Amelipro.
• Croire que mettre à jour WordPress suffit : la faille est dans PHP, le moteur du site. Les mises à jour du site restent indispensables, mais elles ne corrigent pas PHP.
• Bricoler le réglage vous-même avec une extension ou un fichier ajouté au site : PHP demande de l'appliquer dans la configuration du serveur, sans compter sur un fichier « .user.ini ».
• Répondre à un e-mail qui prétend que votre site a été piraté et réclame une rançon en cryptomonnaie : c'est une arnaque au chantage connue (Cybermalveillance.gouv.fr). Ne payez pas, conservez le message, changez par précaution le mot de passe d'administration du site et signalez-le sur Pharos (ministère de l'Intérieur).

Les signes d'une intrusion à faire vérifier

Un site corrigé aujourd'hui a pu être attaqué avant. Faites-le vérifier sans tarder si vous remarquez :

• Un avertissement de Google : une alerte reçue, un message dans les résultats de recherche ou un problème dans la rubrique « Problèmes de sécurité » de la Search Console (l'outil gratuit de Google pour les propriétaires de sites). Un propriétaire inconnu ajouté à votre Search Console est aussi suspect.
• Des pages que vous n'avez jamais créées : tapez dans Google « site: » suivi de l'adresse de votre site, sans espace. Google cite par exemple des pages de texte japonais généré automatiquement, parfois visibles des seuls moteurs de recherche.
• Des visiteurs redirigés vers un autre site, ou un site défiguré (page noire ou blanche, images sans rapport, mention « hacked »).
• Une activité inhabituelle dans l'administration du site : connexions, articles modifiés, fichiers déposés.
• Un message de votre hébergeur, ou des erreurs inhabituelles dans les journaux du serveur. Mais un journal sans erreur ne prouve pas que le site est sain, prévient PHP.

Si l'intrusion est confirmée : prévenez l'hébergeur, conservez les preuves, déposez plainte, puis corrigez la faille et changez tous les mots de passe avant de remettre le site en ligne (Cybermalveillance.gouv.fr), à partir d'une sauvegarde antérieure à l'incident. Si des données personnelles ont pu être touchées (formulaires, comptes clients), consignez l'incident dans votre registre des violations et, en cas de risque pour les personnes, notifiez-le à la CNIL au plus tard 72 heures après en avoir pris connaissance (voir nos conseils sur les règles RGPD que les indépendants oublient).

On s'en occupe avec vous

Les sites en PHP que nous avons créés et que nous suivons sont hébergés sur des serveurs situés en France : ils font partie des 11 sites vérifiés le 23 octobre. Pour un autre site, votre premier interlocuteur reste votre hébergeur ou votre prestataire ; nous pouvons venir chez vous, à Nancy et dans tout le Grand Nancy, lire avec vous la page d'informations PHP de votre hébergement et préparer votre demande écrite : c'est notre dépannage informatique à domicile, forfait S à 50 € net (jusqu'à une heure). En cas de doute sur une intrusion, notre expertise informatique établit les faits, preuves à l'appui, dans un rapport daté et signé qui peut appuyer une plainte. Et si votre site est ancien et sans suivi, mieux vaut repartir sur des bases saines avec une création ou une refonte de site internet : site vitrine dès 480 € net, e-commerce dès 1 200 € net, contrat reconduit annuellement. Le diagnostic par téléphone est gratuit : appelez-nous au 06 69 61 02 73.

Sources : PHP, annonce du 20 octobre 2026, avis de sécurité du 21 octobre 2026, PHP 8.2.35 et fin de vie de PHP 8.2, avis du 23 octobre 2026, avis détaillés CVE-2026-109618 et CVE-2026-109619 (21 octobre 2026), versions maintenues, versions abandonnées, manuel : phpinfo, progression d'un téléversement en session et configuration des sessions, et code source de phpinfo (en anglais pour la plupart) ; CERT-FR (ANSSI), alerte CERTFR-2026-ALE-014 (21 octobre 2026, mise à jour du 27 octobre 2026) ; Cybermalveillance.gouv.fr, AlerteCyber sur les failles critiques dans PHP (22 octobre 2026), défiguration de site Internet (mise à jour du 28 octobre 2026), comment sécuriser son site Internet (mise à jour du 6 mai 2026) et chantage au site Internet prétendu piraté (mise à jour du 8 avril 2026) ; NCSC-NL (Pays-Bas), dépôt php2shell (2 novembre 2026, en anglais) ; CloudLinux, état des paquets PHP corrigés (21 octobre 2026, mise à jour du 28 octobre 2026, en anglais) ; Red Hat, rétroportage des correctifs de sécurité (en anglais) ; Assurance maladie, page de maintenance d'Amelipro ; Egora, Amelipro toujours en panne (23 octobre 2026) et retour à la normale progressif (27 octobre 2026) ; CNIL, violations de données personnelles : les règles à suivre ; Google, rapport sur les problèmes de sécurité, comment savoir si mon site a été piraté et piratage par mots clés japonais ; exigences techniques de WordPress, PrestaShop et Joomla (en anglais).