Faille de sécurité PHP (PHP2Shell) : ce qu’il faut savoir et les mesures prises par EasyWeb Studio

Une vulnérabilité dans une technologie utilisée par des millions de sites fait légitimement réagir. Elle ne signifie pas pour autant qu’un site a été attaqué, ni qu’il est en danger une fois les correctifs appliqués. Cet article fait le point, sources officielles à l’appui, sur ce que sont ces failles, ce qu’elles auraient pu permettre et ce que nous avons fait.

1. PHP, le moteur invisible de WordPress

PHP est un langage de programmation exécuté côté serveur. Lorsqu’un visiteur ouvre une page d’un site WordPress, c’est PHP qui interroge la base de données, assemble le contenu et renvoie la page au navigateur. Le visiteur ne le voit jamais, mais sans lui, le site ne fonctionne pas.

WordPress, WooCommerce, Drupal, Joomla ou PrestaShop reposent tous sur PHP. C’est ce qui explique l’ampleur de cette alerte : la faille ne se trouve pas dans un thème, une extension ou le code d’un site, mais dans l’interpréteur PHP installé sur le serveur. Un site parfaitement à jour côté WordPress dépend donc aussi de la version de PHP installée sur son serveur.

2. PHP2Shell : les faits vérifiés

Le 20 octobre 2026, l’équipe de sécurité de PHP a annoncé une publication de sécurité exceptionnelle, après la diffusion prématurée d’informations sur ces failles. Les correctifs ont été publiés le 21 octobre 2026 à 14 h UTC (16 h à Paris). Le CERT-FR, centre gouvernemental de veille et d’alerte rattaché à l’ANSSI, et le CERT-EU ont publié des alertes le même jour.

Dans les deux cas, l’équipe PHP indique qu’un attaquant pourrait, sans authentification, faire exécuter du code sur le serveur au moyen de requêtes HTTP spécialement construites. Tous les modes d’exécution de PHP servant des pages web sont concernés (PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP, LiteSpeed), le risque étant jugé le plus élevé avec mod_php.

Versions concernées et versions corrigées

Point important : ce n’est pas le numéro de branche qui protège, mais la présence du correctif. Une version 8.4 antérieure à 8.4.27 reste vulnérable, sauf si l’éditeur du système a intégré le correctif dans son propre paquet.

La note de gravité varie selon les organismes : l’équipe PHP retient 9,2 sur 10, tandis que Red Hat, par exemple, estime l’exploitation plus difficile dans les configurations PHP-FPM courantes. Le CERT-FR indique avoir connaissance de preuves de concept pour des déploiements spécifiques, et plusieurs sociétés de sécurité ont signalé des tentatives d’exploitation sur Internet. C’est précisément pour cette raison que l’application rapide des correctifs était la mesure recommandée par toutes les autorités.

3. Quels risques concrets dans un scénario défavorable ?

Une exécution de code à distance est l’une des catégories de vulnérabilités les plus sérieuses, car elle permet potentiellement d’agir sur le serveur lui-même. Sur un serveur non corrigé et effectivement visé, un tel mécanisme pourrait, selon la configuration, permettre :

• l’accès à des informations confidentielles présentes sur le serveur (fichiers de configuration, données de la base) ;
• la modification non autorisée de contenus ou de fichiers du site ;
• l’interruption du fonctionnement du site ;
• l’utilisation abusive des ressources du serveur, par exemple pour envoyer des courriels indésirables ;
• dans les cas les plus graves, la compromission de l’environnement d’hébergement concerné.

Ces scénarios décrivent ce que la faille rendait techniquement possible. Ils ne décrivent pas ce qui s’est produit. En matière de sécurité, il faut distinguer cinq situations très différentes :

4. EasyWeb Studio : les mesures prises pour renforcer la sécurité des environnements concernés

Dès la publication de l’alerte, nous avons agi selon une démarche simple : suivre les sources officielles, coordonner l’intervention et informer nos clients.

• Prise en compte de l’alerte dès l’annonce de l’équipe PHP et des autorités de cybersécurité.
• Coordination avec notre partenaire technique pour planifier et réaliser l’intervention sur l’infrastructure d’hébergement.
• Mise à jour des environnements concernés vers PHP 8.4 avec les correctifs de sécurité appropriés.
• Information des clients hébergés par courriel.
• Suivi des recommandations publiées par PHP, le CERT-FR et le CERT-EU.

Vous n’avez aucune manipulation à effectuer au titre de cette intervention. Vos sites, vos contenus et vos accès restent inchangés. Cette réactivité illustre le rôle d’un hébergement accompagné : la surveillance des alertes et l’application des correctifs font partie intégrante de la protection d’un site, au même titre que les sauvegardes. Pour en savoir plus sur notre offre, consultez notre page hébergement web.

5. Pourquoi les mises à jour et la maintenance comptent

Aucun logiciel n’est exempt de failles. Ce qui fait la différence, c’est le délai entre la publication d’un correctif et son application. PHP2Shell l’a montré : en quelques heures, des organisations du monde entier, y compris des administrations françaises, ont mis des sites en maintenance préventive le temps d’appliquer les correctifs.

6. Une faille dans une technologie tierce : comment la lire

Les vulnérabilités PHP2Shell se situent dans le langage PHP, une technologie open source maintenue par sa propre communauté et utilisée par une très large partie du web. Une vulnérabilité affectant une technologie tierce ne caractérise pas, à elle seule, un défaut de conception propre au site ni un manquement d’EasyWeb Studio. Les circonstances, les obligations applicables et les mesures effectivement prises doivent être appréciées au regard de la situation concernée.

Notre rôle, en tant que prestataire, est de suivre ces alertes et de coordonner l’application des correctifs appropriés aux environnements concernés. C’est ce que nous avons fait.

Questions fréquentes

Qu’est-ce que PHP2Shell ?

C’est le surnom donné par les chercheurs et la presse à deux vulnérabilités critiques du langage PHP, CVE-2026-109618 et CVE-2026-109619, corrigées le 21 octobre 2026. Elles pouvaient permettre l’exécution de code à distance sans authentification sur un serveur non corrigé.

Mon site WordPress a-t-il été piraté ?

L’existence d’une faille ne signifie pas qu’un site a été compromis. Si vous remarquez un comportement inhabituel (pages modifiées, redirections, alertes de votre navigateur), contactez-nous pour que nous puissions vérifier la situation.

Dois-je faire quelque chose ?

Non. Si votre site est hébergé par EasyWeb Studio, l’intervention a été coordonnée de notre côté. Aucune manipulation ne vous est demandée à ce titre.

Le passage à PHP 8.4 peut-il affecter mon site ?

PHP 8.4 est une version activement maintenue par le projet PHP. Si vous constatez une anomalie d’affichage ou de fonctionnement, signalez-la depuis votre espace client ou notre page contact.

Les extensions de sécurité WordPress protègent-elles contre ces failles ?

Pas complètement. La faille se situe dans PHP, en amont de WordPress. L’équipe PHP précise que seule la mise à jour constitue une solution complète, les mesures de contournement ne faisant que réduire certaines voies d’attaque.

Les failles de sécurité font partie de la vie des technologies numériques. Ce qui protège un site, c’est un suivi attentif et des correctifs appliqués rapidement. C’est l’engagement d’EasyWeb Studio envers ses clients, aujourd’hui comme lors des prochaines alertes.