Comment Upsun a géré la faille PHP2Shell : une protection mise en place 22 heures avant la sortie du correctif

Le 21 octobre 2026, l'équipe derrière PHP a publié un correctif d'urgence pour deux failles de sécurité critiques. PHP est le langage de programmation qui sous-tend une grande partie du Web, notamment WordPress, Drupal et de nombreuses boutiques en ligne. Les chercheurs de Wiz ont baptisé ces failles « PHP2Shell ». Un pirate pourrait les exploiter pour prendre le contrôle d'un site Web sans même avoir à se connecter.

Mettre à jour un site web, son CMS ou ses plugins ne sert à rien. La seule vraie solution, c’est (et c’était) une nouvelle version de PHP elle-même.

Sur Upsun Cloud, on avait mis en place des règles WAF environ 22 heures avant que ce correctif n’existe. Les clients n’ont rien eu à faire. Dès que l’équipe PHP a publié les correctifs, on a appliqué les correctifs et redémarré les sites concernés pour eux, y compris ceux fonctionnant sur d’anciennes versions de PHP que PHP lui-même ne prend plus en charge.

Voici comment ça s’est passé. Toutes les heures sont en UTC.

L'alerte (20 octobre)

PHP a annoncé à l’avance qu’un correctif critique allait sortir le lendemain. Il y avait quelques détails, mais c’était surtout un avertissement.

Ça a suffi pour commencer à protéger les clients d’Upsun Cloud. Chaque visite sur un site hébergé chez Upsun passe d’abord par notre couche périphérique, une couche de protection entre Internet et les applications de nos clients. Une modification à ce niveau protège tous les clients d’un seul coup, sans toucher à leur code.

Nos ingénieurs ont rapidement mis en place de nouvelles règles pour bloquer les types de requêtes les plus susceptibles de déclencher la faille. À 15 h 50, ces règles bloquaient déjà les attaques dans toutes les régions. Le correctif officiel n’allait être publié que près d’un jour plus tard.

Le jour de la divulgation (21 octobre)

Le matin : on se prépare

À 8 h 40, on a ouvert un incident et réparti le travail. Un groupe s’est concentré sur le correctif. Un autre s’est chargé de tenir les clients informés. On a appris des incidents passés que les mêmes personnes ne peuvent pas bien gérer les deux en même temps.

À 9 h 45, notre page d’état et un article de blog étaient en ligne. Les deux disaient la même chose aux clients : la protection est déjà en place, et tu n’as rien à faire. Notre équipe d’assistance a utilisé une réponse standard pour chaque question, pour que tout le monde reçoive le même message.

Tout au long de la matinée, les ingénieurs ont continué à renforcer la protection en ajoutant de nouvelles règles.

Midi : les attaquants passent à l’action tôt

En fin de matinée, les attaquants parcouraient déjà Internet à la recherche de sites vulnérables, plusieurs heures avant que PHP ne publie la moindre information. Nos règles de périphérie les ont détectés et bloqués. À 12 h 50, on a informé les clients sur la page d’état qu’on constatait des attaques et qu’ils étaient déjà protégés.

Après-midi : le correctif arrive

PHP a publié le correctif vers 13 h 36, un peu en avance sur le calendrier prévu. Il couvrait les versions actuelles de PHP, ainsi que les anciennes versions que PHP ne prend plus en charge.

En général, ce sont les clients qui décident quand déployer les mises à jour de leur plateforme. Mais pour une faille aussi grave, on ne voulait pas que tu aies à attendre. On a donc pris les devants et appliqué le correctif pour toi.

On l’a fait avec précaution. La mise à jour n’a remplacé que PHP lui-même. Elle n’a touché ni au code ni à la configuration de personne. Chaque nouvelle version a été testée dans une région distincte avant d’atteindre le site d’un seul client. Et si un projet comportait des modifications en attente de mise en production, on ne les a pas déployées. On a plutôt contacté le responsable, pour que rien n’atteigne l’environnement de production avant qu’il ne décide de les publier.

La seule interruption prévue était une brève actualisation pour appliquer le correctif. Pendant cette actualisation, Upsun met en attente les requêtes de pages entrantes jusqu’à ce que le site soit prêt ; ainsi, la plupart des visiteurs ont constaté un chargement plus lent des pages plutôt que des erreurs.

En fin d’après-midi, toutes les règles de protection étaient activées dans toutes les régions, bloquant environ 1 700 requêtes malveillantes par heure, provenant pour la plupart d’outils d’attaque automatisés.

• 18 h 02 : Toutes les versions actuelles de PHP ont été corrigées dans toutes les régions de Upsun Cloud.
• 19 h 13 : On a publié un article technique détaillé pour les développeurs sur l’Upsun Developer Center.
• 19 h 36 : Les correctifs pour les anciennes versions ont commencé à être déployés.

En soirée : les anciennes versions

Appliquer les correctifs aux versions actuelles, c'était la partie la plus prévisible. Le plus dur, c'était tout le reste.

• Les anciennes versions que PHP ne prend plus en charge : corrigées le soir même. Les clients qui les utilisaient ont reçu le correctif sans avoir à effectuer de mise à jour.
• Les versions trop anciennes pour être corrigées : on a contacté directement chaque client concerné, pour que personne n’ait à l’apprendre via une page d’état.
• Les sites qui ne pouvaient pas être mis à jour automatiquement : on a aussi contacté directement leurs propriétaires.

À 23 h 35, la page d'état a confirmé que toutes les régions d'Upsun Cloud avaient été mises à jour.

Le lendemain matin (22 octobre)

À 04 h 12, les derniers correctifs étaient en place et la page d'état est passée en mode surveillance. Quelques petites opérations de nettoyage se sont poursuivies tout au long de la journée.

Ce qui a fait la différence

Une couche de protection devant chaque site. Ça fait partie de la façon dont Upsun gère la sécurité, et c’est la seule raison pour laquelle on a pu protéger tous nos clients avant même qu’un correctif n’existe, sans demander à personne de changer quoi que ce soit.

On gère PHP nous-mêmes. Quand PHP a publié des correctifs pour des versions qu’il ne prend plus en charge, on a pu les mettre en place le jour même.

On a pris les devants, en toute sécurité. On a appliqué le correctif de manière proactive, donc aucun site n’est resté exposé pendant qu’une mise à jour attendait dans la file d’attente. Ça n’a modifié que PHP, jamais le code ou la configuration des clients, et rien n’a été mis en ligne sans qu’ils aient choisi de le publier.

Des rôles clairs dès le départ. Les ingénieurs pouvaient se concentrer sur les corrections. Les clients obtenaient toujours des réponses claires et cohérentes.

Ce que tu devrais faire

• Tu utilises une version prise en charge de PHP ? Rien à faire. Tu es déjà à jour.
• Tu utilises une très ancienne version de PHP ? Prépare une mise à jour. Notre protection réduit le risque, mais elle ne remplace pas un correctif.
• Tu n’es pas sûr ? Demande à tes développeurs de consulter l’article du Centre des développeurs, ou ouvre un ticket depuis la console Upsun.
• Tu utilises PHP ailleurs ? Assure-toi qu’il soit également mis à jour là-bas.

Pour consulter l'historique complet des incidents, rends-toi sur la page d'état.

Pour les détails techniques, notamment les versions concernées et comment vérifier ton environnement, lis l’article « Correctifs de sécurité critiques pour PHP : déploiement par Upsun et vérifications à effectuer » sur le Centre des développeurs Upsun.