Sécurité
Faille PHP PHP2Shell : vérifier sa version, mettre à jour
PHP2Shell (CVE-2026-109618) : corrigée en PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Vérifiez votre version de PHP, interrogez l’hébergeur. Au 23 oct. 2026.
- Par IT bugsolutions
- 12 min de lecture
Le 21 octobre 2026, le projet PHP a corrigé deux failles critiques, regroupées sous le nom PHP2Shell (CVE-2026-109618 et CVE-2026-109619). Elles touchent PHP lui-même, donc presque tous les sites qui l’utilisent, WordPress et boutiques en ligne compris. La seule chose à faire maintenant : trouver la version de PHP de votre hébergement et demander à votre hébergeur de confirmer que le correctif est en place. Sont corrigées les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35, ou plus récentes.
- PHP2Shell = CVE-2026-109618 et CVE-2026-109619 (CVSS 4.0 : 9,2). Versions corrigées : PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35 (21 octobre 2026). PHP 8.1 et antérieures ne reçoivent aucune mise à jour du projet PHP.
- À faire maintenant : trouvez votre version de PHP (étapes plus bas), comparez-la au tableau et demandez à votre hébergeur de confirmer par écrit que le correctif est en place. Sur un hébergement mutualisé, le numéro de version seul ne prouve rien.
- Des tentatives d’exploitation sont confirmées, une exploitation réussie à grande échelle ne l’est pas.
- Seule la mise à jour règle le problème. Les réglages temporaires ne couvrent pas tout.
Publié le 23 octobre 2026. La situation évolue vite. Les sources en bas de page font foi, pas ce résumé.
Qu’est-ce que PHP2Shell ?
PHP2Shell est le nom donné à deux failles critiques de PHP (CVE-2026-109618 et CVE-2026-109619), pas de WordPress ni d’une extension. Sans même se connecter, un attaquant peut potentiellement faire exécuter du code sur votre serveur : c’est l’exécution de code à distance. Le projet PHP leur a attribué un score CVSS 4.0 de 9,2 sur 10.
En termes simples, il s’agit de gestion de la mémoire. Conséquence possible : du code exécuté avec les droits du processus web, et des données en mémoire (mots de passe, jetons) qui peuvent fuiter. Des chercheurs de Calif (avec OpenAI) et de Wiz les ont trouvées à l’aide de modèles d’IA. Toute installation PHP qui traite des requêtes web est concernée en principe, par exemple PHP-FPM ou Apache mod_php.
Quelle version de PHP est corrigée contre PHP2Shell ?
Est corrigée la version indiquée pour votre branche, ou toute version plus récente. Le tableau reprend la position du projet PHP au 21 octobre 2026. La CVE-2026-115560 (voir plus bas) n’est pas corrigée par ces versions.
| Version de PHP | Situation | Ce que vous faites |
|---|---|---|
| 8.5 | Corrigée en 8.5.12 | Passez à la 8.5.12 ou plus récente. |
| 8.4 | Corrigée en 8.4.27 | Passez à la 8.4.27 ou plus récente. |
| 8.3 | Corrigée en 8.3.36 | Passez à la 8.3.36 ou plus récente. |
| 8.2 | Corrigée en 8.2.35. Mises à jour de sécurité jusqu’au 31 décembre 2026. | Mettez à jour maintenant et prévoyez un passage à la 8.3 ou plus récente. |
| 8.1 et antérieures | Aucune mise à jour du projet PHP. Seulement des correctifs à compiler soi-même pour les 7.4, 8.0 et 8.1. Certaines distributions peuvent publier leur propre correctif. Pour la 7.3 et les antérieures, il n’existe aucun correctif. | Demandez à votre hébergeur s’il propose un correctif, ou migrez vers une version encore prise en charge. |
Source : projet PHP, avis de sécurité et notes de version, 21 octobre 2026.
Comment vérifier la version de PHP de votre site ?
Vous la trouvez dans l’espace de votre hébergeur ou dans WordPress. Les noms de menus varient selon l’hébergeur et la version de WordPress. Si vous ne trouvez pas, demandez simplement à votre hébergeur.
- cPanel : ouvrez « Select PHP Version » ou « MultiPHP Manager ». La version choisie apparaît pour chaque domaine.
- Plesk : allez dans Sites web et domaines, puis dans les paramètres PHP de votre domaine.
- WordPress : menu Outils, Santé du site, onglet Info, section Serveur. La version de PHP y figure.
Les hébergeurs corrigent parfois la version sans changer son numéro, ou appliquent des protections au niveau du serveur. Hostinger cite par exemple une date de compilation du 21 octobre 2026 ou postérieure dans « PHP Info ». Le plus sûr est de poser la question à votre hébergeur : « Mon site tourne-t-il sur une version qui contient le correctif, pour la version de PHP que j’ai choisie ? »
Si vous créez un fichier phpinfo() temporaire, supprimez-le aussitôt : il affiche des informations sensibles. php -v sur le serveur donne la version en ligne de commande, pas forcément celle de votre site.
Comment mettre à jour PHP sur votre hébergement ?
Chez la plupart des hébergeurs, vous choisissez vous-même la version de PHP. Cela relève de la pratique courante, pas d’une source officielle, et les noms de menus varient. Faites d’abord une sauvegarde et testez votre thème et vos extensions.
- Ouvrez votre espace : dans cPanel « Select PHP Version » ou « MultiPHP Manager », dans Plesk les paramètres PHP de votre domaine.
- Choisissez une version que votre hébergeur confirme comme corrigée, de préférence la 8.3 ou plus récente.
- Chargez le site, la page de connexion et, pour une boutique, le paiement, puis vérifiez que tout fonctionne.
- Demandez à votre hébergeur de confirmer que les processus PHP ont été redémarrés après la mise à jour. Le projet PHP présente ce redémarrage comme faisant partie de la solution.
Choisir une version dans l’espace client n’aide que si l’hébergeur a lui-même mis à jour cette version. Si le site ne fonctionne plus après le changement (par exemple erreur HTTP 500), revenez à la version précédente et lisez que faire quand un site est cassé après une mise à jour ou consultez notre intervention quand un site est en panne.
Vous ne savez pas ce que vous voyez ? Envoyez-nous le nom de votre hébergeur et votre version de PHP via le formulaire de contact. Le diagnostic est gratuit.
Cette faille PHP est-elle déjà exploitée ?
Des tentatives sont confirmées, une exploitation réussie à grande échelle ne l’est pas. Gardez les deux faits en tête. Les sources ne disent pas toutes la même chose (situation au 23 octobre 2026) :
- CISA n’observait aucune exploitation le 21 octobre. Selon watchTowr et Tenable, les failles ne figuraient pas au 22 octobre dans son catalogue KEV (liste des failles connues comme exploitées).
- watchTowr signale des tentatives depuis le 21 octobre dans ses propres pièges (honeypots), sans identifier les auteurs.
- Rapid7 rapporte des tentatives mais n’a pas observé d’exploitation lui-même. Les démonstrations publiques ne fonctionnent que pour certaines combinaisons de système, de version de PHP et de serveur web.
- NCSC-NL examinait le 22 octobre de premiers signes d’exploitation réussie. Le 23 octobre, il a jugé l’exploitation complexe et une attaque de grande ampleur moins probable qu’on ne le pensait d’abord, avec un seul signalement non confirmé à l’étranger.
- BSI (Allemagne) ne fait état d’aucun succès à grande échelle confirmé, mais de signalements non confirmés d’exploits existants.
Pour vous, cela veut dire : pas de panique, mais pas de raison d’attendre non plus. Le correctif existe et le conseil reste de mettre à jour, même sans signe d’exploitation.
D’autres systèmes que WordPress sont-ils concernés ?
Peut-être. Les failles sont dans PHP lui-même, pas dans un CMS ni dans une extension. Tout site qui tourne sous PHP peut donc être concerné, qu’il s’agisse de WordPress, Joomla, Drupal, Magento ou d’un développement sur mesure. Ce qui compte, c’est la version de PHP et la version corrigée chez votre hébergeur. Mettre à jour le CMS ou ses extensions ne règle rien.
Que faire si votre hébergeur ne propose pas encore de version corrigée ?
Demandez-lui une confirmation écrite et une échéance, et préparez une solution de remplacement. Le NCSC-NL et Cybermalveillance.gouv.fr conseillent tous deux de contacter l’hébergeur si vous ne gérez pas vous-même votre informatique.
- Demandez à votre hébergeur s’il existe une version avec le correctif pour la version de PHP que vous avez choisie, et pour quand.
- Si possible, passez à une branche encore prise en charge (8.3 ou 8.4). Testez d’abord votre thème et vos extensions.
- Envisagez de changer d’hébergeur pour un autre qui applique les correctifs, ou laissez-nous nous en charger.
- Si vous êtes en PHP 8.1 ou antérieur, votre version est obsolète : prévoyez une migration. Voir aussi les risques d’un logiciel obsolète.
Cybermalveillance.gouv.fr recommande de traiter en priorité les sites qui gèrent des paiements ou des comptes clients.
Note technique, en général pour votre hébergeur : comme mesures temporaires, le projet PHP cite notamment session.upload_progress.enabled=0, une valeur basse pour post_max_size (la taille maximale d’une requête) et aucune limite de mémoire (memory_limit=-1), réglée de façon que les applications ne puissent pas la modifier. Ils se placent dans php.ini ou le pool FPM, suivis d’un redémarrage des processus PHP. Ces réglages réduisent seulement certaines voies d’attaque et ne couvrent pas tout.
La CISA recommande de mettre hors ligne les systèmes qui ne peuvent pas être corrigés ou qui tournent sous PHP 8.1 ou antérieur. Le NCSC-NL parle de les garder hors ligne jusqu’à correction. Le CERT-EU recommande d’isoler les applications exposées à Internet jusqu’à l’application et la vérification du correctif. Le CERT-FR conseille d’isoler puis de migrer vers une version prise en charge. Le BSI ne parle pas de mise hors ligne mais recommande de corriger sans délai. C’est un arbitrage site par site : en cas de doute, demandez conseil.
Comment reconnaître un site éventuellement piraté ?
Une preuve formelle est difficile : presque aucun indicateur de compromission n’est publié pour l’instant. Rapid7 souligne que l’absence de traces dans les journaux ne prouve rien. Les sources citent :
- des processus PHP qui lancent un shell ou téléchargent des outils (CISA) ;
- de nombreuses requêtes d’envoi de gros fichiers suivies d’erreurs de mémoire ou d’erreurs HTTP 500 répétées, des cookies
PHPSESSIDanormalement gros et des redémarrages inexpliqués des processus PHP (Wiz).
Signes généraux de piratage, qui ne sont pas propres à PHP2Shell : fichiers PHP inconnus ou récemment modifiés (surtout dans uploads, tmp ou cache), administrateurs que vous n’avez pas créés, redirections inattendues ou pages de spam, tâches planifiées inconnues, pic soudain de charge ou de trafic. Un doute ? Gardez d’abord une copie de l’état actuel. Associez ensuite votre hébergeur et un spécialiste. Changez mots de passe et clés une fois le nettoyage fait, car des données en mémoire ont pu fuiter. Besoin d’un avis ? Contactez-nous : le diagnostic est gratuit. Lisez les gestes de la première heure après un piratage ou consultez notre intervention sur site piraté.
Existe-t-il une troisième faille (CVE-2026-115560) ?
Oui, mais elle est distincte et, selon le projet PHP, peu probable. Le 23 octobre, PHP a publié une note d’information : l’exploitation suppose qu’une application règle session.serialize_handler sur php_binary ou php_serialize, repasse à php avec ini_set() avant session_start(), et que le suivi de progression des envois (upload progress) soit activé.
Les versions 8.5.12 et suivantes ne la corrigent pas ; l’avis complet suivra avec la prochaine version régulière. Parade : session.upload_progress.enabled=0. Certaines sources parlent d’une « troisième exécution de code à distance » : ne la lisez pas comme aussi grave que les deux premières.
Que pouvons-nous faire pour vous ?
Vous pouvez suivre vous-même les étapes ci-dessus. Si vous êtes bloqué, ou si vous voulez être certain que tout est en ordre, nous prenons le relais à distance :
- Nous vérifions quelle version de PHP votre site utilise réellement et si votre hébergeur a appliqué le correctif.
- Nous passons votre site sur une version de PHP corrigée, puis nous testons que les pages, les extensions et le paiement fonctionnent encore. Si la mise à jour casse quelque chose, nous le réparons.
- Nous recherchons sur votre site des traces d’une intrusion antérieure et nous le nettoyons.
- Nous faisons une sauvegarde avant chaque modification, pour que vous puissiez toujours revenir à l’état actuel.
Le diagnostic est gratuit : il nous permet de déterminer ce qu’il faut faire et combien cela coûte. Vous recevez ensuite un prix fixe avant que nous commencions. Les réparations démarrent à partir de 295 € HT. Nettoyer un site piraté ou réparer une boutique en ligne démarre à partir de 450 € HT. Si nous ne résolvons pas le problème convenu, nous vous remboursons intégralement la somme versée pour cette intervention.
Vous voulez que ces mises à jour se fassent désormais toutes seules ? Avec nos forfaits de maintenance, comme Essential (99 € HT par mois), nous gardons votre site à jour. Si vous soupçonnez déjà une infection, commencez par notre aide en cas de site piraté ou contactez-nous.
Sources et références
- Projet PHP : avis de sécurité et notes de version, 20 au 23 octobre 2026
- CERT-FR : CERTFR-2026-ALE-014
- Cybermalveillance.gouv.fr : alerte sur les failles critiques de PHP
- CISA : Critical Vulnerabilities in PHP Require Immediate Patching (en anglais)
- CERT-EU : Security Advisory 2026-018 (en anglais)
- NCSC-NL : PHP vulnerabilities remain a reason for immediate patching (en anglais)
- BSI : PHP, kritische Schwachstellen (en allemand)
- Wiz Research : PHP2Shell (en anglais)
- watchTowr : FAQ PHP2Shell (en anglais)
- Rapid7 : CVE-2026-109618 et CVE-2026-109619 (en anglais)
- Hostinger : Protecting PHP2Shell (en anglais ; déclaration d’un hébergeur, non vérifiée de façon indépendante)
Questions fréquentes
À voir aussi