En bref : deux vulnérabilités critiques permettant l’exécution de code à distance ont été annoncées dans PHP, le langage qui fait tourner WordPress, WooCommerce, Drupal, Magento et une grande partie des outils internes des entreprises. Les correctifs sortent aujourd’hui. Au-delà de l’urgence technique, cet épisode pose des questions directes de conformité : RGPD, NIS2, DORA. C’est l’angle que cet article développe.
Ce qui s’est passé
Le 20 octobre, un message publié sur le forum Hacker News par un utilisateur nommé « petecooper », supprimé depuis, annonçait la divulgation prochaine de deux failles critiques d’exécution de code à distance dans PHP. La société de sécurité watchTowr a ensuite confirmé sur X que la fuite était authentique et que les deux failles étaient sous embargo jusqu’au jeudi.
L’équipe sécurité de PHP a publié son avis le soir même, à 19h33 UTC, en avançant la publication des correctifs au mercredi, soit un jour avant la date prévue. Elle prévoit la sortie le 21 octobre 2026 à 14h00 UTC et se réserve le droit d’accélérer si les détails deviennent publics ou si une exploitation active apparaît. Cela correspond à 16h00 heure de Paris.
Le CERT-EU, l’équipe de réponse aux incidents des institutions européennes, a publié un avis recommandant de se préparer à corriger immédiatement et, si ce n’est pas possible, d’envisager d’isoler les applications exposées à Internet jusqu’à la disponibilité d’un correctif.
Les deux failles portent les identifiants CVE-2026-109618 et CVE-2026-109619. Les chercheurs ont surnommé l’ensemble « php2shell » ; Ce nom vient d’eux et non de PHP.
En France, le CERT-FR (ANSSI) a publié le 21 octobre l’alerte CERTFR-2026-ALE-014. Pour les versions de PHP qui ne sont plus maintenues (5.x, 6.x, 7.x, 8.0.x et 8.1.x), il recommande d’isoler les équipements concernés, puis de migrer vers une version maintenue et corrigée dès la sortie du correctif.
Qui est derrière « PHP2Shell » ?
Le nom ne vient pas d’un groupe criminel. Selon Sansec, en même temps que l’avis, une capture d’écran a fuité. Elle montre un outil d’exploitation baptisé PHP2Shell et attribué à Calif.IO, dont la bannière affirme fonctionner sur toutes les versions publiées depuis PHP 5.4.0. D’après la fiche CVE de Tenable, ce sont les chercheurs de Calif qui ont donné ce nom à une chaîne d’exploitation : l’une des failles combinée à une autre vulnérabilité de PHP permet d’exécuter du code à distance. Le chercheur Will Dormann a aussi relayé une capture issue d’une vidéo de Calif suggérant que leur preuve de concept fonctionne contre WordPress.
Autrement dit, des chercheurs disposent déjà d’un exploit fonctionnel. La seule question est de savoir combien de temps il faudra aux attaquants pour le reconstituer.
Distinguer le confirmé de la rumeur
Beaucoup d’articles mélangent les deux.
L’affirmation selon laquelle toutes les versions depuis PHP 5 seraient concernées n’est pas confirmée. La FAQ de watchTowr elle-même précise que ce périmètre n’a pas été validé par un avis officiel et qu’aucune condition de configuration n’a été décrite. Des hypothèses techniques circulent aussi sur X sur le composant fautif. Elles ne sont pas vérifiées, et nous ne les reprenons pas ici.
Exploitation : la situation évolue d’heure en heure.
Mardi soir, Huntress et watchTowr ne signalaient aucune exploitation. Mais d’après la chronologie tenue par Sansec, Cloudflare a signalé ce matin à 9h43 (heure de Paris) des premières attaques et a déployé des règles de pare-feu applicatif. Sansec s’attend à des attaques à grande échelle dans le quart d’heure qui suivra la publication des correctifs, car la comparaison entre l’ancien et le nouveau code révélera la faille à tous.
Deux autres signaux comptent pour les équipes techniques. Un développeur du cœur de PHP a insisté sur le fait que seul le correctif règle le problème. Les contournements du CERT-FR (voir plus bas) permettent seulement de réduire le risque en attendant. La PHP Foundation a aussi prévenu que le dépôt de Remi, très utilisé sur les serveurs Red Hat, AlmaLinux et Rocky, n’aura pas de mise à jour aujourd’hui.
9,2 ou 10 ? Le chiffre qui en dit plus qu’il n’y paraît
C’est le point que la plupart des articles survolent. watchTowr et le message de Hacker News parlent d’un score CVSS de 10, alors que l’équipe PHP attribue à chaque faille un score de 9,2 en CVSS v4.0.
Ces deux chiffres ne se contredisent pas forcément : ils ne sont pas mesurés sur la même échelle. Le « 10 » renvoie très probablement à l’ancienne version de la grille, la CVSS 3.1. Le « 9,2 » officiel est calculé avec la version 4.0, qui ajoute un critère absent de la v3.1 : les Attack Requirements (prérequis d’attaque). Ce critère mesure si l’attaque dépend de conditions propres au déploiement ciblé, comme une configuration particulière ou un état précis du serveur.
Notre lecture :
L’alerte du CERT-FR va dans ce sens : elle rattache au moins l’une des failles à une fonctionnalité précise, le suivi de progression des envois de fichiers, et aux requêtes d’envoi de fichiers. Mais cette fonctionnalité est activée par défaut dans PHP. La « condition » que traduit le 9,2 sera donc remplie sur une grande partie des serveurs qui n’ont pas modifié leur configuration. Le 9,2 ne doit en aucun cas être lu comme un signe de risque modéré.
Conséquence pratique : ne vous rassurez pas avec le 9,2, et ne cédez pas à la panique avec le 10. Préparez-vous à tout corriger, puis utilisez l’avis officiel pour prioriser.
Le vrai piège : les versions de PHP en fin de vie
Seules les quatre branches encore supportées, de 8.2 à 8.5, peuvent recevoir le correctif. Toutes les versions plus anciennes, y compris 8.1, 8.0, 7.x et 5.x, sont en fin de vie et ne recevront aucun correctif de PHP. Si les failles les concernent, ces installations resteront sans patch officiel.
L’ampleur du problème est réelle. L’éditeur Mallory a recensé via Shodan, le 20 octobre, environ 884 000 serveurs exposés sur Internet dont l’en-tête HTTP affichait une version de PHP 8.1 ou antérieure, soit 59 % des quelque 1,5 million de serveurs qui indiquaient une version. Ce chiffre repose sur ce que les serveurs déclarent, pas sur des systèmes confirmés vulnérables. Il donne néanmoins un ordre de grandeur.
Pour une PME, le risque se cache souvent ici : Un vieux site vitrine, un extranet développé il y a cinq ans, un outil métier installé par un prestataire et jamais mis à jour.
Que faire, concrètement
Avant 16h aujourd’hui
Les contournements provisoires du CERT-FR (non qualifiés par le CERT-FR, donc à tester avant de les généraliser) :
- Désactiver le suivi de progression des envois de fichiers dans le fichier
php.ini:session.upload_progress.enabled = OffSi vous utilisez PHP-FPM, il faut aussi modifier la configuration du pool :php_admin_flag[session.upload_progress.enabled] = off
Cette fonctionnalité sera alors désactivée. Attention : cette mesure ne réduit la surface d’attaque que pour l’une des deux vulnérabilités. - Bloquer les requêtes HTTP dont l’en-tête Content-Type est de type multipart, le format utilisé pour envoyer des fichiers et certains formulaires. Si ce blocage est impossible, le CERT-FR recommande fortement de surveiller ce type de requêtes.
Ces deux mesures peuvent être mises en place au niveau d’un pare-feu applicatif (WAF).
À savoir avant de bloquer : le blocage des requêtes multipart casse tous les envois de fichiers (pièces jointes, photos, documents dans un formulaire de contact ou un back-office). C’est une mesure d’urgence de quelques heures, pas une solution durable. Elle ne remplace pas le correctif.
À partir de 16h
4. Corrigez en priorité les systèmes exposés à Internet. Si vous êtes sous Linux ou chez un hébergeur, vérifiez la disponibilité des paquets corrigés de votre distribution.
5. Pour les versions en fin de vie : mettre à niveau, retirer le système d’Internet, ou le placer derrière un VPN ou un pare-feu applicatif (WAF) en attendant.
Dans les jours qui suivent
6. Surveillez ce que lance PHP. Une exploitation se traduira probablement par des processus PHP (php-fpm, php-cgi, httpd, apache2) qui lancent des programmes inhabituels : interpréteurs de commandes, scripts Python ou Perl, outils de téléchargement comme curl ou wget.
7. En cas de doute, isolez le serveur, conservez les journaux du serveur web et de PHP, et recherchez des webshells, de nouveaux fichiers dans le répertoire web, de nouvelles tâches planifiées ou de nouveaux comptes.
Le même jour, une autre alerte : la clé privée qui valait « 4 »
Pendant que la fuite PHP occupait les esprits, un second incident, sans lien technique, a secoué la sécurité du web : celui des certificats eMudhra, une autorité de certification indienne reconnue par tous les navigateurs.
Les faits. eMudhra a révoqué huit certificats intermédiaires compromis. Des chercheurs ont découvert que leurs clés privées étaient si faibles que n’importe qui pouvait les retrouver presque instantanément, puis s’en servir pour fabriquer de faux certificats valides au nom de sites légitimes. Un chercheur connu sous le nom de Wayne a repéré le problème le 17 octobre en analysant des données publiques de certificats.
Le chiffre 4. Une clé privée de ce type (courbe P-384) devrait être un nombre aléatoire d’environ 115 chiffres. Ici, les huit clés générées en avril 2025 avaient une valeur inférieure à 256 : il suffisait d’essayer 256 nombres pour les retrouver. Pour le démontrer, le chercheur Flüpke a publié l’une d’elles. La clé privée du certificat « EM OV TLS CA – G3C » valait tout simplement 4.
La cause. eMudhra l’attribue à une erreur dans le script de génération d’avril 2025. Ce script aurait produit un second jeu de clés faibles, sélectionnées par erreur parce que leurs libellés ressemblaient à ceux des bonnes clés. Certains de ces certificats avaient même été soumis à Sectigo pour une signature croisée.
L’exposition. L’entreprise affirme que la plupart de ces certificats n’ont jamais servi en production et qu’elle n’a trouvé aucune trace de certificats émis à des utilisateurs finaux. Les clés étaient pourtant récupérables depuis avril 2025, soit 18 mois, même si rien n’indique un abus.
La réponse. Mozilla a bloqué les certificats dans Firefox dès le 17 octobre, sans mise à jour nécessaire. Chrome a bloqué le même jour les six intermédiaires autorisés à émettre des certificats TLS, et Apple a suivi le 19 octobre.
Pourquoi c’est votre problème, même hors navigateur. Les logiciels qui utilisent leur propre magasin de certificats ou ne vérifient pas les révocations peuvent continuer à faire confiance aux certificats compromis. C’est le cas de nombreuses applications serveur, y compris dans l’écosystème PHP : le paquet Composer ca-bundle est corrigé dans les versions 1.4.16 et 1.6.0. À l’heure de la publication, Node.js et le paquet ca-certificates de Debian étaient encore en attente. Un site de suivi tenu par un ingénieur de Mozilla recense les logiciels concernés et propose des points de test.
La leçon commune aux deux affaires. Dans les deux cas, le maillon faible n’est pas votre code. C’est une dépendance à laquelle vous faites confiance sans la voir : le langage qui fait tourner votre site, ou l’autorité qui garantit vos connexions chiffrées. C’est exactement ce que le RGPD (article 28), NIS2 et DORA (gestion des risques liés aux prestataires TIC) vous demandent de cartographier.
L’angle que personne ne traite : vos obligations réglementaires
Une faille de cette ampleur n’est pas seulement un sujet pour les équipes techniques. C’est aussi un test de votre conformité.
RGPD : sécurité du traitement (article 32). Le RGPD impose des mesures techniques et organisationnelles « appropriées ». Laisser tourner en production une version de PHP sans support, sur un site qui collecte des données personnelles, devient difficile à justifier une fois qu’une faille critique publique ne sera jamais corrigée sur cette version. Si un incident survient, la question de la CNIL portera aussi sur ce que vous aviez fait pour l’éviter.
RGPD : violation de données (articles 33 et 34). Si un serveur est compromis et que des données personnelles ont pu être consultées ou exfiltrées, vous disposez de 72 heures pour notifier la CNIL lorsque la violation présente un risque pour les personnes, et vous devez informer les personnes concernées si ce risque est élevé. Une exécution de code à distance donne en général accès à tout ce que le serveur peut lire, base de données comprise.
RGPD : vos sous-traitants (article 28). Votre hébergeur, votre agence web ou l’éditeur de votre outil métier sont souvent vos sous-traitants au sens du RGPD. C’est le bon moment pour vérifier que vos contrats prévoient la gestion des correctifs de sécurité et l’information en cas d’incident, et pour leur demander une confirmation écrite de la correction.
NIS2 et DORA. Si votre organisation entre dans le champ de NIS2, ou de DORA pour le secteur financier, la gestion des vulnérabilités et le suivi des prestataires TIC font partie de vos obligations. Un incident significatif lié à cette faille déclencherait des délais de notification courts : alerte précoce sous 24 heures et notification sous 72 heures pour NIS2, et classification puis déclaration des incidents majeurs liés aux TIC pour DORA.
Notre conseil : documentez.
Notez la date à laquelle vous avez pris connaissance de l’alerte, l’inventaire réalisé, les décisions prises pour chaque système et la date d’application des correctifs. En cas de contrôle ou d’incident, cette traçabilité montrera votre diligence. Sans elle, il est difficile de démontrer quoi que ce soit.
