PHP2Shell : retour sur notre intervention

Dans cet article, nous allons faire un retour sur notre intervention comme suite à ce que la petite histoire retiendra sûrement pour longtemps comme « les deux failles PHP2Shell ».

Nous commencerons par fournir des renseignements généraux sur l’intervention de PlanetHoster et nous expliquerons pourquoi nos clients ne doivent pas s’inquiéter. Par la suite, les personnes versées dans les aspects plus techniques pourront consulter les détails susceptibles de les intéresser.

L’intervention de PlanetHoster

Comme nous le savons tous, le Web n’a pas fini de nous réserver des surprises. Nous en avons eu une démonstration éloquente, tout récemment, ce 20 octobre pour être plus précis. N’eût été de la prudence et du sens des responsabilités de PlanetHoster envers ses clients, les conséquences auraient pu être désastreuses.

Heureusement, strictement rien de fâcheux n’est arrivé.

PlanetHoster, fidèle au poste, était là ces derniers jours pour vous appuyer à 100 %. Jugez-en plutôt.

Un retour en arrière : que s’est-il passé?

Le 20 octobre 2026, l’équipe de sécurité de PHP annonçait dans le monde entier une publication d’urgence pour le lendemain, le 21 octobre à 14h00 TUC¹, afin de corriger deux vulnérabilités critiques : CVE2026-109618 et CVE-2026-109619, notées 9,2 sur l’échelle CVSS v4.0².

Un nom fut bientôt sur toutes les lèvres pour les évoquer : PHP2Shell.

Par malheur, les détails techniques ont filtré avant la sortie du correctif annoncé. Les failles touchaient session.upload_progress, une fonction du cœur de PHP activée par défaut. Ces failles permettaient une exécution de code à distance, sans authentification, sur tout site qui accepte un formulaire multipart³. Autrement dit, n’importe quel formulaire d’envoi de fichier devenait une porte d’entrée.

Dès le matin du 21 octobre, des tentatives d’exploitation étaient observées sur Internet, avant même que le correctif n’existe. Pour un hébergeur comme PlanetHoster, c’est la pire fenêtre possible : tout le monde sait comment attaquer, et personne n’a encore de quoi se défendre. Pour faire une analogie, l’hébergeur peut se sentir comme l’occupant d’une forteresse entourée d’ennemis dont il ne connaît ni le nombre ni la puissance.

Dans des situations pareilles, il ne faut surtout pas paniquer. Il faut garder la tête froide. Et agir. C’est ce que nous avons fait.

Notre réponse n’a pas tardé…

Le mieux est d’adopter une approche préventive. Mieux vaut prévenir que guérir.

Il était évident que les personnes malveillantes agiraient très vite. Dès lors, nous n’avons pas attendu le correctif de PHP. Les mesures de protection ont été mises en place avant la publication dudit correctif. Qui plus est, elles n’ont été levées qu’après vérification, serveur par serveur.

HybridCloud N0C a fait la différence

Sur N0C, aucun compte n’a dû changer de version de PHP; sur cPanel, les comptes sous 7.4 ont dû être basculés. Plus loin, nous verrons que la raison tient à trois technologies incluses dans N0C, sans aucun frais de licence supplémentaire.

Et maintenant, dois-je faire quelque chose?

Non, nos clients peuvent dormir sur leurs deux oreilles. Aucune action n’est requise de leurs part.

Il faut savoir que PlanetHoster a déployé les correctifs et ils ont été vérifiés. Nos systèmes poursuivent jour et nuit les mises à jour en parallèle.

Si une erreur venait à être constatée sur un formulaire, notre clientèle est invitée à contacter notre support.

Pour ceux qui sont sur HybridCloud cPanel avec une configuration personnalisée ou qui dépendent d’une version de PHP antérieure à 7.4, nos techniciens peuvent évaluer ce qui est possible ou les accompagner dans une migration vers HybridCloud N0C. Sans frais. Ils y retrouveront leur version de PHP, maintenue, avec le noyau (kernel) live patch et l’isolation par projet en prime.

Les détails…

Pour nos lecteurs dont les connaissances techniques le permettent, nous proposons ici davantage de détails qui, nous l’espérons, les intéresseront.

• Nous commencerons par analyser dans le détail notre contre-attaque.
• Nous reviendrons sur quelques faits marquants.
• Nous expliquerons les trois technologies qui expliquent pourquoi HybridCloud N0C a fait toute la différence.

Notre réponse, heure par heure

Comme nous l’avons dit plus haut, les mesures de protection ont été en place avant la publication du correctif et n’ont été levées qu’après vérification, serveur par serveur.

Voici ce que nous avons fait (heures de Montréal).

Les faits marquants

Voici quelques éléments à retenir.

Protégés avant le correctif, pas après. Les mesures de protection étaient actives avant la publication du correctif, donc avant les premières tentatives d’exploitation. Les sites sont restés en ligne pendant toute l’opération.

Le numéro de version ne dit pas tout. Sur cPanel, les correctifs ont été rétroportés dans les paquets existants. Autrement dit, ea-php74 reste en 7.4.33 et ea-php85 reste en 8.5.11 alors que, pourtant, ils contiennent les deux correctifs. C’est pourquoi nos vérifications portent sur le contenu des paquets, pas sur le numéro affiché. Un simple php -v ne prouve rien.

Pas de levée sans contrôle. La protection n’a été retirée sur un serveur qu’une fois tous ses paquets PHP analysés et confrontés aux deux CVE. Le risque à éviter : corriger, lever la protection, puis voir un client basculer vers une version non corrigée et se faire compromettre dans la foulée.

Toutes les versions, pas seulement les récentes. PHP n’a corrigé que les branches 8.2 à 8.5. Sur HybridCloud N0C et The World, nos versions 5.2 à 5.6, 7.0 à 7.4 et 8.0 à 8.5 ont toutes reçu les correctifs grâce à notre support à long terme. Sur cPanel, hors CloudLinux, les versions antérieures à 7.4 ne sont plus corrigées : les comptes touché ont été basculés vers 7.4.

PHP 4.4 et 5.1 tirent leur révérence. Certains serveurs incluaient encore ces deux versions dans leur éventail, pour une compatibilité maximale. Elles ont reçu des correctifs rétroportés pendant des années, mais elles ont été retirées.

Node.js aussi. En parallèle, les correctifs pour CVE-2026-111497 (Node2Shell) ont été déployés sur l’ensemble de nos serveurs.

Pourquoi HybridCloud N0C a fait la différence?

Nous avons déjà noté que cet incident a mis en lumière une différence concrète entre nos infrastructures puisque, sur N0C, aucun compte n’a dû changer de version de PHP, tandis que sur cPanel, les comptes sous 7.4 ont dû être basculés. La raison tient à trois technologies natives dans N0C.

Sur cPanel, hors CloudLinux, les versions de PHP antérieures à 7.4 ne reçoivent plus de correctifs. C’est exactement le genre de contrainte que le support à long terme de N0C fait disparaître : vous choisissez la version dont votre application a besoin et nous nous chargeons de la garder sécuritaire.

Suivi

L’avis complet et l’historique des mises à jour restent disponibles sur php21oct.planethoster.live.

1. UTC en anglais. ↩︎
2. Le CVSS v4.0 (Common Vulnerability Scoring System version 4.0) est un standard ouvert et universel, géré par le FIRST.Org. Il permet d’évaluer, de mesurer et de communiquer la sévérité des vulnérabilités de sécurité informatique de manière objective. ↩︎
3. Un formulaire multipart (multipart/form-data en langue anglaise) est un type de contenu HTTP (Content-Type) qui permet d’envoyer des données mixtes (du texte et des fichiers ou du contenu binaire) dans une seule et même requête HTTP. ↩︎