Le 21 octobre 2026, PHP a corrigé deux failles critiques, CVE-2026-109618 et CVE-2026-109619, surnommées PHP2Shell. Sans compte ni mot de passe, un attaquant peut exécuter du code sur un serveur web qui fait tourner PHP. Pour un MSP, la gravité n’est plus la question : il faut savoir où tourne PHP chez chaque client, et qui doit le mettre à jour.
Que se passe-t-il avec PHP depuis le 20 octobre ?
Des détails sur deux failles ont circulé le 20 octobre, et la société de recherche watchTowr les a confirmés. Le soir même, l’équipe PHP annonçait une publication de sécurité d’urgence pour le lendemain à 14 h UTC (16 h à Paris). Les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35 sont sorties le 21 octobre.
Les deux failles ont chacune une note CVSS v4.0 de 9,2. La première (CVE-2026-109618) exploite une corruption de la mémoire quand PHP manque de mémoire pendant le traitement d’une requête. La seconde (CVE-2026-109619) exploite un état laissé en mémoire d’une requête à la suivante, notamment par le suivi de progression des envois de fichiers (session.upload_progress). Selon les avis de PHP, l’exécution de code à distance a été validée sur Apache avec mod_php pour les deux failles, et sur PHP-FPM pour la seconde. Pour la première, PHP-FPM est jugé vulnérable par analyse du code, sans exploit complet démontré.
Les attaques n’ont pas attendu le correctif. Cloudflare a signalé des premières attaques dès la matinée du 21 et a déployé des règles de filtrage (WAF) pour ses clients. Aux Pays-Bas, des institutions, dont la Tweede Kamer (le parlement), ont coupé des services par précaution.
| Élément | Valeur publiée | Source |
|---|---|---|
| Identifiants | CVE-2026-109618, CVE-2026-109619 | PHP |
| Note | CVSS v4.0 9,2 chacune | PHP |
| Impact | Exécution de code à distance sans authentification | PHP |
| Versions corrigées | 8.5.12, 8.4.27, 8.3.36, 8.2.35 | PHP |
| PHP 8.1 et plus ancien | Plus de correctif publié par le projet PHP | PHP |
| Portée | Tout serveur web en PHP 5.4 ou plus récent | Sansec |
Qui est concerné chez vos clients ?
Toute installation de PHP qui répond à des requêtes web : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed, selon la liste publiée par PHP. Chez une PME, cherchez :
- les sites web en PHP (WordPress, PrestaShop, Drupal, Joomla, Magento, Laravel), chez un hébergeur ou sur un serveur du client ;
- les serveurs Linux ou Windows qui portent PHP, y compris une pile WAMP ou XAMPP installée un jour pour un test et jamais retirée ;
- les applications métier à interface web et les intranets hébergés en interne ;
- les NAS qui font tourner un serveur web ;
- les conteneurs Docker construits sur une image PHP.
Les deux dernières catégories sont les plus souvent oubliées : personne ne les voit comme « un serveur PHP ».
Quel plan d’action pour un MSP, et dans quel ordre ?
- Inventorier. Listez les machines où PHP est installé et la version en place (
php -vsur un serveur). Pour les sites hébergés, notez l’hébergeur et l’offre. - Classer par exposition. Un site ou une application accessible depuis Internet passe avant un outil interne. Commencez par ce qui reçoit des formulaires et des envois de fichiers.
- Corriger, ou obtenir une date. Sur les serveurs que vous gérez, installez la version corrigée de votre branche. Sur un hébergement mutualisé, c’est l’hébergeur qui met PHP à jour : demandez-lui la date, par écrit. Sur RHEL et ses dérivés, vérifiez votre dépôt : le dépôt Remi n’avait pas le correctif le 21 octobre. Pour Docker, reconstruisez l’image à partir d’une image de base corrigée, puis redéployez.
- Redémarrer. Après la mise à jour, redémarrez PHP-FPM ou le serveur web. Sinon, l’ancienne version reste chargée en mémoire.
- Couper si vous ne pouvez pas corriger. Le CERT-EU demande de patcher immédiatement et, à défaut, d’envisager d’isoler d’Internet les applications exposées.
- Vérifier. Contrôlez la version réellement servie, pas seulement celle du paquet. Relisez les journaux du serveur web à la recherche d’envois de fichiers (requêtes multipart) inhabituels depuis le 20 octobre.
- Prévenir le client. Dites-lui ce qui était exposé, ce qui est corrigé et ce qui attend l’hébergeur.
Les branches 8.1 et plus anciennes ne reçoivent plus de correctif du projet PHP. Certaines distributions et éditeurs de support long fournissent un correctif rétroporté : demandez-le. Sinon, la seule sortie est la montée de version, avec les tests applicatifs qu’elle suppose. Et notez la date suivante : PHP 8.2 ne recevra plus de correctif de sécurité après le 31 décembre 2026.
Qu’est-ce qui ne protège pas ?
Les réglages de php.ini qui circulent sur les réseaux ne suffisent pas. L’équipe PHP l’écrit dans chaque annonce : il n’existe pas de parade complète, la mise à jour est le seul choix sûr. Gina Peter Banyard, de l’équipe du cœur de PHP, le résume ainsi : « la seule parade, c’est de mettre à jour PHP ». Désactiver session.upload_progress ou modifier memory_limit ferme certains chemins d’attaque, pas la faille.
Un WAF devant le site aide, à condition que tout le trafic passe par lui. Il ne voit pas une application interne, ni une variante d’attaque qu’il ne connaît pas encore.
Comment en parler à votre client ?
Le client veut savoir s’il est concerné et ce que vous faites. Trois phrases types, à adapter :
- « Une faille critique touche PHP, le langage de votre site. Nous avons vérifié vos machines : deux sont concernées, la mise à jour est faite ce soir. »
- « Votre site est hébergé chez [hébergeur], c’est lui qui met PHP à jour. Nous lui avons demandé la date et nous vous la transmettons dès réception. »
- « Votre application [nom] tourne sur une version de PHP qui ne reçoit plus de correctif. Nous proposons de la couper d’Internet en attendant une montée de version, que nous chiffrons cette semaine. »
Que change la supervision NeoOne ce jour-là ?
Le jour où une faille sort, un MSP se juge au temps qu’il met à répondre à « est-ce qu’on est concernés ? ». Avec NeoOne, l’inventaire logiciel de la console liste les logiciels installés sur les postes et serveurs supervisés. Une recherche sur « php » sort en quelques minutes les machines qui portent PHP, WAMP ou XAMPP, client par client. Vous savez qui est exposé, et vous appelez le client avant qu’il ne vous appelle. C’est le même réflexe que pour le Patch Tuesday d’octobre et la fin de Windows Server 2012.
Deux limites, à dire clairement. Les sites installés chez un hébergeur ne figurent pas dans cet inventaire, puisque ce ne sont pas des machines supervisées : tenez à part la liste des sites et de leurs hébergeurs. Et la mise à jour de PHP reste un geste de votre équipe, à planifier puis à vérifier. NeoOne vous dit où agir ; c’est déjà ce qui manque le plus le premier jour.
Voir l’inventaire NeoOne en 30 minutes
Vous voulez voir comment retrouver un logiciel sur le parc de vos clients ? Nathanael Berthe, fondateur de NeoOne Expert, vous montre la console NeoOne en visio : réserver une démo de 30 minutes.
Questions fréquentes
Un site WordPress est-il concerné par PHP2Shell ?
Oui, tant que le serveur ne fait pas tourner PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 ou une version corrigée par sa distribution. WordPress fonctionne avec PHP, et la faille est dans PHP : mettre à jour WordPress ne la corrige pas.
Faut-il redémarrer après la mise à jour de PHP ?
Oui. PHP-FPM ou le serveur web garde l’ancienne version en mémoire tant qu’il n’a pas été redémarré.
Que faire d’un serveur en PHP 8.1 ou plus ancien ?
Le projet PHP ne publie plus de correctif pour ces branches. Demandez à votre distribution ou à votre éditeur de support long s’il fournit un correctif rétroporté. Sinon, isolez l’application d’Internet et planifiez la montée de version.
Article rédigé le 21 octobre 2026 à partir des publications de PHP, du CERT-EU, de Sansec et de Cloudflare.
Sources
- PHP, « Critical remote code execution vulnerabilities, update now » (21 octobre 2026)
- PHP, avis GHSA-w8hw-w9fx-j79w, CVE-2026-109618 (21 octobre 2026)
- PHP, avis GHSA-6wmf-4rv5-p3rp, CVE-2026-109619 (21 octobre 2026)
- CERT-EU, Security Advisory 2026-018, Critical Vulnerabilities in PHP
- Sansec, PHP2Shell (21 octobre 2026)
- Cloudflare, protections WAF contre php2shell
- The Hacker News, ce qui protège et ce qui ne protège pas avant le correctif
- Precursor Security, chronologie de PHP2Shell