Faille critique PHP2Shell : ce qui s'est passé et que faire

En bref : une faille de PHP permettait de prendre le contrôle d'un serveur à distance. Le correctif est sorti le 21 octobre 2026 vers 16 h : votre site doit tourner sur une version corrigée.

PHP fait fonctionner la grande majorité des sites et des logiciels web : WordPress, PrestaShop, Joomla, Drupal, mais aussi les sites, applications SaaS et ERP développés sur mesure. Voici, sans jargon, qui est concerné, comment vérifier votre site, et comment nous avons réagi sur nos serveurs le jour même.

1. La faille en quelques mots

SurnomPHP2Shell
RéférencesCVE-2026-109618 et CVE-2026-109619
GravitéCritique : 9,2 sur 10
RisqueExécution de code à distance

Deux erreurs dans PHP lui-même permettent à un attaquant d'exécuter ses propres commandes sur le serveur en lui envoyant une simple requête web. Le problème se situe dans la façon dont PHP lit certaines données envoyées par les formulaires, avant même que le code du site ne démarre : un site bien programmé et parfaitement à jour était donc exposé quand même. Avec ce genre d'accès, un pirate peut lire la base de données, installer un logiciel malveillant ou se servir du serveur pour attaquer d'autres sites.

Les détails ont fuité le 20 octobre, la veille du correctif prévu. Selon la société de sécurité Sansec, des premières attaques ont été observées dès le matin du 21 octobre. Le CERT-FR, le centre de veille de l'ANSSI, a publié une alerte le jour même, et PHP a sorti ses correctifs vers 16 h.

2. Votre site est-il concerné ?

Tout dépend de la version de PHP utilisée par votre hébergement :

Version de PHPSituation
8.2, 8.3, 8.4, 8.5Corrigé à partir des versions 8.2.35, 8.3.36, 8.4.27 et 8.5.12
8.0 et 8.1Aucun correctif officiel : ces versions ne sont plus maintenues
7.x et plus ancienneAucun correctif officiel : il faut changer de version

Versions d'après l'avis CERTFR-2026-AVI-1359 du 21 octobre 2026.

Le type de site ne change rien : une vitrine WordPress, une boutique PrestaShop ou un logiciel métier développé sur mesure sont exposés de la même manière, puisque c'est PHP qui est en cause et non le site.

3. Vérifier sa version de PHP sans être informaticien

Si la version affichée n'apparaît pas comme corrigée dans le tableau ci-dessus, ou si vous ne trouvez pas l'information, demandez à votre hébergeur ou à votre prestataire de confirmer par écrit que le correctif est installé.

4. Que faire, selon votre hébergement

  1. Hébergement mutualisé (OVHcloud, o2switch, IONOS…) : l'hébergeur applique lui-même les correctifs de PHP. Vérifiez seulement que votre site n'est pas resté réglé sur une ancienne version (7.x, 8.0, 8.1), et changez-la dans l'espace client après avoir testé le site.
  2. Serveur dédié ou VPS : la mise à jour de PHP est de votre responsabilité ou de celle de votre prestataire. Elle doit être faite dès maintenant, puis le serveur redémarré proprement et chaque site vérifié.
  3. Ancienne version sans correctif : le seul vrai remède est la migration vers une version maintenue. Elle demande de vérifier que le site et ses extensions fonctionnent avec la nouvelle version, ce qui peut prendre quelques heures pour un vieux site.
  4. En attendant le correctif : une protection temporaire existe, mais le CERT-FR précise qu'elle ne couvre qu'une des deux failles. Elle fait gagner du temps, elle ne remplace pas la mise à jour.

Votre site tournait sur une version touchée et le correctif a tardé ? Faites vérifier les journaux et les fichiers du serveur à la recherche d'une intrusion. Si des données de clients ou de salariés ont pu être consultées, la CNIL doit être prévenue, si possible sous 72 heures, et le service public 17Cyber peut vous orienter.

5. Pourquoi un pare-feu ne suffit pas

Nos serveurs sont reliés à un réseau de bannissement partagé : une adresse qui attaque l'un d'eux est bloquée sur tous les autres en quelques minutes. C'est très efficace contre les robots qui frappent sans cesse aux mêmes portes, comme le montrent les attaques reçues en direct en Marne et Haute-Marne.

Une faille comme PHP2Shell est différente : la porte est dans le logiciel lui-même, et une requête venue d'une adresse jamais vue peut suffire. Le bannissement réduit le risque pendant les heures d'attente du correctif, mais la seule protection complète reste la mise à jour, appliquée vite, puis vérifiée site par site.

6. Notre réaction, heure par heure

Voici ce qui a été fait le 21 octobre 2026 sur les serveurs qui hébergent les sites, les applications SaaS et les ERP de nos clients :

  1. MatinLecture de l'alerte, puis inventaire : quelles versions de PHP tournent, quels sites et quelles applications les utilisent. Tous les sites en PHP sont concernés.
  2. 15 h 54Protection temporaire appliquée sur nos serveurs, sans coupure de service.
  3. Vers 16 hDès la publication du correctif officiel, vérification qu'il corrige bien les deux failles, puis installation sur nos serveurs.
  4. De 16 h à 17 h 45Test de chaque site web, de chaque application SaaS et de chaque ERP, page par page, en comparant leur comportement avant et après. Les principales applications qui tournaient encore sur une ancienne version de PHP ont été migrées vers une version corrigée, avec les mêmes réglages.
  5. BilanTous les sites et applications sont restés en ligne et aucune intrusion n'a été constatée. Une veille automatique des alertes officielles est en place pour les prochaines failles.

Les dernières alertes de sécurité officielles sont affichées et mises à jour sur la page des cyberattaques en Marne et Haute-Marne.

Qui s'occupe des correctifs de votre site ?

Si j'héberge votre site, les mises à jour de sécurité sont comprises dans l'hébergement à 190 € par an, selon l'architecture du site, avec le serveur en France, les sauvegardes et le réseau anti-cyberattaques. Si vous gérez votre propre serveur, la protection par bannissement partagé (390 € puis 29 € par mois) bloque les attaquants, mais les correctifs restent à votre charge ou se font sur devis.

Faire vérifier mon site
Voir la protection de serveur →
Ce que les robots cherchent sur un serveur →

7. Questions fréquentes

Mon site WordPress est-il concerné par la faille PHP2Shell ?

Oui, si la version de PHP de votre hébergement n'est pas à jour : WordPress fonctionne avec PHP, et la faille se situe dans PHP lui-même, pas dans WordPress. Mettre à jour WordPress et ses extensions ne suffit donc pas : c'est la version de PHP qui doit être corrigée.

Mon site est chez un hébergeur mutualisé : que dois-je faire ?

Les grands hébergeurs installent eux-mêmes les correctifs de PHP. Votre rôle : vérifier dans votre espace client que votre site n'utilise pas une ancienne version (7.x, 8.0 ou 8.1), qui ne recevra aucun correctif, et la faire passer à une version récente après avoir testé le site.

Comment savoir si mon site a été piraté par cette faille ?

Les signes habituels d'un site piraté sont à surveiller : pages inconnues, redirections vers d'autres sites, comptes administrateurs que vous n'avez pas créés, alerte de Google. Pour cette faille, seule l'analyse des journaux et des fichiers du serveur permet de conclure : demandez-la à votre hébergeur ou à votre prestataire si votre site tournait sur une version touchée.

Le pare-feu ou le bannissement des attaquants suffisent-ils ?

Non. Ils bloquent les robots déjà repérés et les attaques connues, mais une faille dans PHP peut être exploitée par une adresse jamais vue. Ils réduisent le risque pendant les quelques heures d'attente du correctif ; la mise à jour reste la seule vraie protection.

Mon site tourne en PHP 7.4 : que faire ?

Aucun correctif officiel n'est prévu pour PHP 7.4, ni pour les versions 8.0 et 8.1. Il faut passer à une version maintenue (8.2 ou plus récente) après avoir vérifié que le site fonctionne avec elle. En attendant, faites limiter au maximum ce que le serveur accepte, et surveillez-le.

Qu'est-ce qu'une CVE ?

C'est le numéro d'identification international d'une faille de sécurité, par exemple CVE-2026-109618. Il permet aux éditeurs, aux hébergeurs et aux autorités comme le CERT-FR de parler exactement de la même faille.

Faut-il porter plainte ou prévenir la CNIL ?

Seulement si une intrusion est constatée. Si des données personnelles (clients, salariés) ont pu être consultées ou volées, la notification à la CNIL est à faire dans les meilleurs délais, si possible sous 72 heures, et une plainte permet de faire jouer votre assurance. Le service public 17Cyber peut vous orienter.

Les mises à jour de sécurité sont-elles comprises chez Reims Digital ?

Oui pour les sites que j'héberge (190 € par an), selon l'architecture du site : c'est ce qui a été fait le 21 octobre. Pour un serveur que vous gérez vous-même, la protection par bannissement partagé (390 € puis 29 € par mois) ne comprend pas les correctifs : ils restent à votre charge ou se font sur devis.

Article rédigé par Alexandre Léger, développeur web freelance à Reims depuis 2005, qui héberge et administre les sites, applications SaaS et ERP de ses clients. Sources : CERT-FR, alerte CERTFR-2026-ALE-014 ; CERT-FR, avis CERTFR-2026-AVI-1359 ; annonces de sécurité de PHP ; Sansec, PHP2Shell. Publié le 21 octobre 2026.