Illustration éditoriale générée par IA — professionnelle et bureau fictifs, sans représentation d’une attaque réelle. Créée avec Imagegen pour Uminov.
Les correctifs contre PHP2Shell sont disponibles depuis le 21 octobre 2026. Ce nom désigne deux failles critiques, CVE-2026-109618 et CVE-2026-109619, qui peuvent permettre l’exécution de code à distance sans authentification. Pour un artisan, un commerçant ou une petite entreprise disposant d’un site, la priorité est de faire vérifier la version de PHP réellement utilisée par son hébergement. [1]
Un risque qui concerne le serveur du site
PHP est un langage exécuté côté serveur, utilisé par de nombreuses applications web. Le CERT-FR signale les branches anciennes et les versions non corrigées des branches récentes. Un site vitrine, une boutique ou un outil professionnel peut donc nécessiter une intervention même si ses pages restent accessibles. Une apparence normale ne prouve pas que le moteur PHP est corrigé. [2]
Il faut également distinguer exposition et intrusion : utiliser une version vulnérable ne signifie pas qu’un site a forcément été piraté. Dans son billet du 21 octobre, Amazon Threat Intelligence rapporte des tentatives observées dès le 17 octobre dans ses capteurs, sans établir leur réussite sur des systèmes réels. AWS indique aussi une exploitation dans la nature après la divulgation. Cela justifie une prise en charge rapide, sans attribuer automatiquement toute panne à PHP2Shell. [5]
Mettre à jour WordPress ne suffit pas
La correction se fait au niveau de PHP, distinct du logiciel WordPress. L’équipe WordPress précise qu’aucune mise à jour de WordPress n’est prévue pour résoudre ces deux failles. Mettre à jour ses extensions reste une démarche de maintenance utile, mais ne remplace pas la correction du moteur fourni par l’hébergeur. [3]
Dans un site WordPress, la version déclarée de PHP se trouve dans Outils → Santé du site → Informations → Serveur. Le panneau d’hébergement peut aussi l’indiquer. Relevez cette information pour votre prestataire ; n’en déduisez pas seul que le serveur est protégé ou compromis. Si vous utilisez une plateforme entièrement gérée, demandez au fournisseur sa confirmation pour votre service, plutôt que d’appliquer une procédure destinée à un serveur administré par vos soins. [3]
Les versions corrigées à faire confirmer
Le projet PHP a publié quatre versions de sécurité pour ses branches stables maintenues. Le repère porte sur la branche déjà utilisée : il ne s’agit pas de basculer sans préparation tous les sites vers la même version. [1]
Branche utilisée | Version amont corrigée publiée le 21 octobre |
|---|---|
PHP 8.2 | 8.2.35 |
PHP 8.3 | 8.3.36 |
PHP 8.4 | 8.4.27 |
PHP 8.5 | 8.5.12 |
Un numéro plus ancien peut toutefois correspondre à un paquet corrigé par une distribution. Canonical fournit par exemple le correctif d’Ubuntu 24.04 dans le paquet 8.3.6-0ubuntu0.24.04.13. Le numéro complet et l’avis du fournisseur comptent donc davantage que le seul début « 8.3.6 ». Canonical rappelle aussi que les services utilisant PHP peuvent devoir être redémarrés pour employer les composants mis à jour. [4]
Les branches PHP 8.1 et antérieures ne sont plus maintenues par le projet PHP. Des fournisseurs proposent néanmoins des correctifs rétroportés ; PHP a aussi publié des correctifs sources minimaux pour certaines anciennes branches. Faites confirmer la solution applicable par l’administrateur, avec une migration vers une branche maintenue à préparer si nécessaire. [1]
Quel professionnel contacter et que lui demander ?
Commencez par identifier qui exploite réellement votre site. Le nom de l’agence qui l’a créé ne suffit pas toujours à déterminer qui assure aujourd’hui l’hébergement et la maintenance.
Votre hébergeur peut confirmer la version de PHP fournie, le paquet corrigé déployé et les actions éventuellement attendues dans votre espace client.
Votre prestataire de maintenance web ou votre administrateur système peut organiser l’intervention, vérifier la compatibilité et contrôler le fonctionnement après la mise à jour, selon son contrat.
Un professionnel de la cybersécurité devient pertinent lorsqu’une intrusion est soupçonnée, pour rechercher les traces et définir une remise en service adaptée. Cybermalveillance.gouv.fr propose une orientation vers une assistance spécialisée. [6]
Pour éviter une réponse trop générale, demandez une confirmation écrite portant sur quatre points :
la version complète de PHP qui sert effectivement votre site ;
la référence du correctif couvrant les deux CVE ;
la prise en compte du redémarrage des services lorsque nécessaire ;
les vérifications réalisées après intervention et les éventuelles anomalies relevées.
Un message indiquant simplement « WordPress est à jour » ne répond pas à ces questions. Gardez également la date d’intervention et le compte rendu : ils permettent de retrouver ce qui a été corrigé si plusieurs prestataires interviennent.
Si la correction ne peut pas être appliquée immédiatement
Une mesure temporaire ne remplace pas le correctif. Le CERT-FR précise que ses contournements ne couvrent pas entièrement le risque. Le CERT-EU recommande d’envisager l’isolement des applications exposées à Internet lorsque la correction immédiate n’est pas possible, jusqu’à son application et sa vérification. Faites décider cette mesure par le responsable technique, en tenant compte des services à interrompre et du moyen de joindre vos clients pendant l’indisponibilité. [2][7]
Ne modifiez pas au hasard les paramètres du serveur et ne considérez pas la présence d’un pare-feu applicatif comme une confirmation de correction. Le point à obtenir reste une réponse précise sur votre hébergement, plutôt qu’une assurance générale sur la sécurité de la plateforme. [3]
En cas de signe d’intrusion, préserver les traces
Si le contenu du site a changé sans votre accord ou si votre prestataire signale une activité suspecte, demandez une analyse avant d’effacer les fichiers concernés. Corriger PHP ne suffit pas à établir qu’aucune intrusion n’a eu lieu auparavant. AWS recommande notamment l’examen des journaux et des modifications inattendues de fichiers ou de processus. [5]
Cybermalveillance.gouv.fr conseille, en cas de défiguration, de contacter l’hébergeur, de préserver les preuves et de se faire assister si nécessaire. Faites conserver les journaux et les éléments utiles à l’analyse ; une restauration précipitée ne doit pas faire disparaître les traces. La remise en ligne doit traiter la cause de l’incident, avec les correctifs et les contrôles adaptés à la situation. [6]
