PHP2Shell : nos sites corrigés en moins de 3 heures

Le 21 octobre 2026, PHP a publié en urgence le correctif de deux failles critiques, CVE-2026-109618 et CVE-2026-109619, surnommées « PHP2Shell ». Une seule requête web, sans authentification, peut suffire à prendre le contrôle d'un serveur, avant même que le code du site ne s'exécute. PHP fait tourner une grande partie du web : sites vitrines, boutiques, CMS, applications métier.

Ce jour-là, nous avons fermé au public tous nos sites et applications PHP accessibles depuis Internet, les avons corrigés, puis rouverts par vagues, au fur et à mesure des corrections. Moins de 3 heures après le début de l'intervention technique, tous nos sites web publics tournaient sur un PHP corrigé, et aucun n'est resté fermé plus de 2 h 15. Voici ce qu'est la faille, ce que recommandaient les autorités, comment nous avons procédé, et ce que nous conseillons de faire si vous utilisez PHP.

PHP2Shell en bref

• Deux failles d'exécution de code à distance dans le cœur de PHP. La première vient de la façon dont PHP s'interrompt quand une requête manque de mémoire : la mémoire de la requête peut rester dans un état incohérent, que le nettoyage de fin de requête traite ensuite comme valide ; avec Apache et mod_php, cela peut se produire avant tout code applicatif. La seconde vient d'un état global qu'un processus garde d'une requête à l'autre et qui pointe encore vers une mémoire libérée.
• Gravité : 9,2 sur 10 selon l'équipe PHP (CVSS 4.0), 9,8 selon la base américaine NVD (CVSS 3.1). Le score de 10,0 qui a circulé avant la publication est faux, selon la PHP Foundation.
• Qui est concerné : toute installation PHP qui sert des pages web, quel que soit le mode (PHP-FPM, Apache avec mod_php, CGI, FrankenPHP, LiteSpeed). L'équipe PHP juge mod_php le plus exposé.
• Versions corrigées : 8.2.35, 8.3.36, 8.4.27 et 8.5.12. Le projet PHP ne met plus à jour les branches 8.1 et plus anciennes : il a seulement fourni des correctifs minimaux sous forme de sources pour 7.4, 8.0 et 8.1, et certaines distributions ou offres de support étendu publient leurs propres correctifs.
• Exploitation : au moment où nous écrivons, elle n'est pas confirmée par le BSI allemand, la CISA américaine ni la PHP Foundation, mais Cloudflare dit avoir observé du trafic d'attaque. Des démonstrations circulaient avant même la publication.

Une publication avancée après une fuite

La correction devait sortir le 22 octobre. Le 20 octobre en fin d'après-midi, les numéros officiels (CVE) des deux failles ont fuité, avec un score et une heure de publication erronés. PHP a donc avancé la publication au 21 octobre à 16h00, heure de Luxembourg, et l'a annoncée le soir même. Peu après, selon la PHP Foundation, une vidéo de démonstration a été publiée par erreur, puis retirée ; des copies ont circulé. Les correctifs sont finalement sortis vers 15h30, une demi-heure avant l'heure annoncée.

Debian et Ubuntu ont publié leurs premiers correctifs dans l'heure (Debian à 15h45, Ubuntu à 15h56). D'autres canaux de distribution n'ont suivi qu'en fin d'après-midi ou en soirée : pendant plusieurs heures, beaucoup d'équipes savaient qu'elles devaient corriger sans disposer encore du paquet qu'elles utilisent d'habitude.

Ce que recommandaient les autorités

• NCSC britannique : à défaut de mise à jour, appliquer les mesures temporaires de PHP ; si c'est impossible ou trop long, envisager de mettre le système hors ligne jusqu'à ce qu'il soit protégé. Un système qui ne peut pas être mis à jour ou désactivé tout de suite doit être examiné avant sa mise à jour ou l'application des mesures temporaires, à la recherche de traces de compromission et de portes dérobées.
• CERT-EU : corriger immédiatement ; à défaut, envisager d'isoler des réseaux publics les applications exposées à Internet jusqu'à ce que le correctif soit appliqué et vérifié.
• BSI (Allemagne) : envisager une déconnexion temporaire d'Internet si les correctifs ne peuvent pas être installés. Le BSI relève que certains opérateurs l'ont fait dans la journée, par précaution.
• CIRCL (Luxembourg) : pour les services exposés à haut risque qui ne peuvent pas être mis à jour, envisager de les isoler ou de les retirer temporairement de l'accès public, selon leur criticité. Le CIRCL met en garde contre une fausse bonne idée : désactiver PHP alors que les fichiers sources restent accessibles par le serveur web. Mieux vaut une page de maintenance sûre ou une restriction réseau.
• CERT-FR : pour les branches en fin de vie (PHP 5 à 8.1), isoler les équipements concernés, puis migrer.

Comment nous avons corrigé nos sites web publics en moins de 3 heures

Voici la chronologie de notre réponse, reconstituée à partir des journaux de nos serveurs et de nos échanges internes (heure de Luxembourg) :

• 15h34 : l'alerte arrive en interne, au moment même où PHP publie ses correctifs.
• 15h57 : décision de prévenir nos clients, de vérifier notre exposition et de fermer les sites qui ne sont pas indispensables. Les premiers clients sont prévenus dès 16h00.
• 16h37 : début de l'intervention technique.
• 16h50 : tous nos sites et applications PHP accessibles depuis Internet sont fermés au public, le dernier à 16h52. Les services continuent de tourner : seul l'accès depuis Internet est bloqué, et les visiteurs voient une page de refus. Les mesures temporaires recommandées par PHP sont appliquées en parallèle à une partie de nos installations.
• De 16h50 à 19h00 : les versions corrigées n'étaient pas encore disponibles dans toutes les images que nous utilisons. Faute de les voir arriver, nous avons reconstruit nous-mêmes, à partir de 18h, les images concernées sur un PHP corrigé, certaines directement à partir des sources officielles de PHP.
• De 18h12 à 19h03 : réouverture par vagues, chaque site seulement après vérification de la version de PHP réellement en service, et pas seulement de la version installée.
• 19h03 : tous nos sites web publics sont rouverts, sur un PHP corrigé, et les réglages temporaires sont retirés. Aucun n'est resté fermé plus de 2 h 15 et, dans les journaux que nous avons examinés, les visiteurs n'ont reçu pendant la fermeture qu'une page de refus, jamais une erreur serveur.
• 20h03 : notre webmail, dont le PHP devait être corrigé à part, rouvre à son tour, après 3 h 13 de fermeture.
• 20h12 : le PHP système de notre serveur de développement est mis à jour à son tour.

Moins de 3 heures se sont donc écoulées entre le début de l'intervention technique et la réouverture de tous nos sites web publics, corrigés. Depuis la publication du correctif, il a fallu environ 3 h 30 : entre la sortie des correctifs vers 15h30 et la fermeture de nos sites à 16h50, il s'est écoulé environ 1 h 20, le temps de décider, de prévenir nos clients, puis de lancer l'intervention.

Pourquoi fermer à Internet plutôt qu'arrêter les services

Couper brutalement un serveur ou désactiver PHP paraît plus sûr. En pratique, cela crée d'autres risques : des pages d'erreur, des traitements interrompus en cours de route et, comme le rappelle le CIRCL, des fichiers sources qui peuvent devenir lisibles si PHP est désactivé alors que le serveur web continue de servir le site. Nous avons préféré fermer l'accès depuis Internet au niveau du serveur web :

• le public ne peut plus atteindre la faille depuis Internet, ce qui réduit fortement l'exposition ;
• les services continuent de tourner, et nos équipes y gardent accès pour corriger et vérifier ;
• chaque site peut être rouvert séparément, dès que sa propre correction est vérifiée ;
• le retour en arrière se fait en une seule commande, sans redémarrage.

Ce que nous en retenons

• Pouvoir fermer à Internet en quelques minutes : une fermeture simple et réversible, qui laisse tourner les services, peut se mettre en place vite le jour de l'alerte ; préparée et testée à l'avance, elle se déclenche plus vite encore.
• Ne pas dépendre d'une seule source de paquets : savoir reconstruire ses images à partir des sources officielles évite d'attendre la mise à jour d'un tiers.
• Vérifier la version qui tourne, pas celle qui est installée : un service qui n'a pas redémarré continue d'exécuter l'ancien code.
• Tout inventorier : serveurs, conteneurs, images de construction, postes de développement. PHP se cache à beaucoup d'endroits.
• Prévenir tôt : nous avons commencé à prévenir nos clients près d'une heure avant la fermeture des sites.

Que faire si vous utilisez PHP

1. Inventoriez tout ce qui exécute PHP et répond à des requêtes web : serveurs, conteneurs, CMS comme WordPress, applications hébergées par un prestataire.
2. Mettez à jour vers 8.2.35, 8.3.36, 8.4.27 ou 8.5.12, ou vers le paquet corrigé de votre distribution, qui peut garder un ancien numéro de version (le correctif y est rétroporté), puis redémarrez les processus PHP et reconstruisez les images de conteneurs.
3. Si vous ne pouvez pas mettre à jour tout de suite, appliquez les mesures temporaires publiées par PHP et fermez l'accès depuis Internet, ce que les autorités invitent à envisager. L'un et l'autre réduisent le risque sans le supprimer : seule la mise à jour corrige.
4. Pour PHP 8.1 et plus ancien, installez le correctif de votre distribution ou de votre support étendu s'il existe, sinon isolez ; dans tous les cas, migrez vers une branche maintenue : le projet PHP ne met plus ces branches à jour.
5. Vérifiez la version réellement en service sur chaque site, et pas seulement le paquet installé.
6. Cherchez des traces de compromission dans vos journaux, comme le demande le NCSC, et en cas de doute, faites-vous accompagner.
7. Si votre site est hébergé, demandez à votre hébergeur quand et comment il a corrigé, et faites-le-vous confirmer par écrit.

Pour une entité soumise à NIS 2, cette réactivité n'est pas une option : la directive range parmi les mesures minimales « la sécurité de l’acquisition, du développement et de la maintenance des réseaux et des systèmes d’information, y compris le traitement et la divulgation des vulnérabilités » (article 21). Si des données personnelles ont pu être exposées, le RGPD impose d'évaluer la violation et, le cas échéant, de la notifier à la CNPD dans les 72 heures (article 33).

Comment Luxgap peut vous aider

Notre SOC managé surveille vos systèmes en continu et vous accompagne en cas d'incident. Pour organiser la gestion des vulnérabilités dans la durée, notre CISO externalisé pilote la politique de sécurité, les risques et les incidents, et un audit de cybersécurité fait l'état des lieux de votre exposition. Une question sur PHP2Shell ou sur votre propre exposition ? Contactez-nous.

Sources

• php.net, annonces du 21 octobre 2026 ; PHP Foundation, 21 octobre 2026
• CVE-2026-109618 ; CVE-2026-109619
• NCSC, Critical security issue affecting PHP ; CERT-EU, avis 2026-018
• CIRCL, TR-102 ; CERT-FR, CERTFR-2026-ALE-014
• NVD, CVE-2026-109618 ; Cloudflare, 21 octobre 2026 ; BSI, BITS-H n° 2026-297981-1132, version 1.1 du 21 octobre 2026

Voir aussi : Comprendre NIS 2 · Comprendre le RGPD · SOC managé