Ajouter comme source préférée sur Google
Le 21 octobre 2026, des pirates ciblaient déjà des sites web à l’aide de requêtes conçues pour exploiter deux failles critiques de PHP, connues sous le nom de « PHP2Shell ». Les correctifs de sécurité officiels n’étaient pas encore disponibles, mais nos équipes d’ingénierie et de sécurité s’étaient déjà mises au travail pour protéger les sites hébergés par Kinsta.
Cette intervention comportait plusieurs volets. Notre équipe a activé des règles de pare-feu Cloudflare d’urgence, ajusté les configurations PHP et s’est préparée à déployer les correctifs sur des centaines de milliers de conteneurs dès qu’ils seraient disponibles. Parallèlement, notre équipe de support répondait à un afflux de questions de clients inquiets pour leurs sites web.
Au 23 octobre, nos protections Cloudflare avaient bloqué plus de 550.000 requêtes ciblant ces vulnérabilités. Nous avions également déployé les mises à jour de sécurité PHP nécessaires sur l’ensemble de notre plateforme d’hébergement et n’avons constaté aucun signe de violation réussie.
Voici comment s’est déroulée l’intervention, depuis les premiers signes d’exploitation jusqu’au déploiement des correctifs et au travail qui a suivi.
Se préparer à PHP2Shell avant la disponibilité des correctifs
Le 20 octobre, l’équipe de sécurité PHP a annoncé la publication imminente d’un correctif de sécurité critique, prévue pour le lendemain. L’annonce mettait en garde contre deux vulnérabilités présentant un indice de gravité CVSS 4.0 de 9,2 et encourageait les utilisateurs de PHP à se préparer à mettre à jour leurs installations dès que les correctifs seraient disponibles.
Ces vulnérabilités, identifiées par la suite sous les références CVE-2026-109618 et CVE-2026-109619, affectent la gestion de la mémoire interne de PHP et pourraient, dans certaines conditions, permettre à des attaquants d’exécuter du code à distance sans authentification.
Cette annonce revêtait une importance particulière pour les sites WordPress, car c’est PHP qui exécute l’application elle-même. La mise à jour d’une extension ou d’un thème WordPress ne suffisait pas à corriger ces vulnérabilités. C’est l’environnement d’exécution PHP sous-jacent qui nécessitait des correctifs de sécurité.
Pour les hébergeurs tels que Kinsta, le premier défi consistait à protéger les sites web avant que les correctifs officiels ne soient disponibles. Notre équipe a commencé à se préparer à cette publication, mais des tentatives d’exploitation faisaient déjà leur apparition.
Selon Laszlo Farkas, directeur de l’ingénierie chez Kinsta, notre équipe a commencé à observer des requêtes ciblant ces vulnérabilités aux premières heures du 21 octobre. Les ingénieurs ont vérifié manuellement les sites visés et ont continué à surveiller l’activité à la recherche de signes indiquant une intrusion réussie.
À ce moment-là, nous avions déjà pris des mesures pour protéger les sites web hébergés sur notre plateforme.
Comment nous avons activé les règles WAF d’urgence de Cloudflare
Chaque site web hébergé sur Kinsta est protégé par Cloudflare, y compris les environnements de production et de staging. Cela permet à notre équipe d’ingénierie d’appliquer des protections par pare-feu à l’ensemble de la plateforme d’hébergement sans que les clients aient à configurer de règles pour chaque site web individuellement.
Avant la divulgation publique de la faille PHP2Shell, Cloudflare a mis en place des règles d’urgence du pare-feu d’applications web (WAF) afin de détecter les tentatives d’exploitation. Notre équipe d’ingénieurs a suivi de près le journal des modifications du WAF de Cloudflare à mesure que de nouvelles règles étaient disponibles, les a examinées et a défini leur action sur « Bloquer » dès que possible.
Comme chaque site Kinsta est déjà protégé par Cloudflare, nous avons pu appliquer ces protections à l’ensemble de notre plateforme d’hébergement, couvrant à la fois les environnements de production et de staging, sans que nos clients aient à intervenir.
Cette protection à l’échelle de la plateforme était essentielle, car PHP2Shell n’était pas une vulnérabilité classique au niveau de l’application. Les attaques visaient PHP lui-même ; par conséquent, les mises à jour de sécurité de WordPress ou les protections au niveau des extensions n’auraient pas résolu le problème sous-jacent.
Les règles du WAF nous ont permis de bloquer les tentatives d’exploitation connues pendant que nous préparions les correctifs PHP. Cloudflare a continué à mettre à jour ses protections à mesure que les attaquants modifiaient leurs techniques. Son rapport technique sur PHP2Shell décrit comment les attaquants ont modifié leurs charges utiles pour contourner les détections existantes.
Cloudflare a également mis en place une détection complète des transactions, qui analyse à la fois les signaux provenant de la requête HTTP et de la réponse du serveur. Cela fournit des informations supplémentaires pour identifier les requêtes suspectes et permet d’empêcher qu’une réponse correspondante n’atteigne le demandeur.
Nos ingénieurs ont pu observer l’évolution des schémas d’attaque à mesure que de nouvelles règles étaient mises en place.
Au 23 octobre, les protections Cloudflare couvrant les sites Kinsta avaient bloqué plus de 550.000 requêtes ciblant PHP2Shell.
Ce chiffre correspond aux requêtes bloquées liées à ces vulnérabilités, et non aux compromissions réussies ni au nombre d’attaquants distincts. Il reflète le trafic suspect traité par nos protections pare-feu pendant que l’équipe travaillait au déploiement des correctifs PHP.
Ajout de protections temporaires au niveau de la configuration PHP
Nous ne nous sommes pas appuyés uniquement sur Cloudflare. En attendant les paquets PHP corrigés, notre équipe d’ingénieurs a également déployé des modifications de configuration PHP sur l’ensemble de nos environnements d’hébergement afin de réduire l’exposition aux vecteurs d’exploitation connus.
L’une de ces modifications consistait à désactiver la fonctionnalité de suivi de la progression du téléversement de session de PHP à l’aide du paramètre session.upload_progress.enabled.
L’avis de sécurité de PHP identifie ce réglage comme une mesure d’atténuation pour certaines voies d’exploitation. Sa désactivation permet de bloquer les attaques qui s’appuient sur la gestion de la progression des téléversements de session par PHP, bien qu’elle ne couvre pas toutes les façons possibles d’exploiter ces vulnérabilités.
Les règles de pare-feu et les modifications de configuration ont apporté une protection supplémentaire tant que les correctifs n’étaient pas disponibles ou étaient encore en cours de déploiement. Toutefois, la mise à jour de l’environnement d’exécution PHP restait nécessaire.
Le 23 octobre, l’équipe PHP a publié un avis supplémentaire recommandant de laisser la fonctionnalité de suivi de la progression des téléversements en session désactivée jusqu’à la sortie d’une prochaine version corrective. Cela a renforcé la mesure de précaution que notre équipe d’ingénieurs avait déjà prise.
Nos règles Cloudflare et nos mesures de protection de configuration locales sont restées en place tout au long du déploiement des correctifs, que chaque environnement ait reçu ou non son paquet PHP mis à jour.
Déploiement des correctifs PHP sur des centaines de milliers de conteneurs
Lorsque l’équipe de développement PHP a publié les mises à jour de sécurité le 21 octobre, notre prochain défi a consisté à déployer ces correctifs sur l’ensemble de l’infrastructure d’hébergement.
Les versions officielles comprenaient PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12. Cependant, Kinsta prend également en charge des versions plus anciennes de PHP, qui nécessitaient des correctifs de sécurité fournis par des responsables de maintenance tiers.
Nous avons collaboré avec Freexian, notre fournisseur de paquets PHP, afin d’obtenir des paquets corrigés pour les versions de PHP exécutées sur notre plateforme, y compris les anciennes versions bénéficiant d’un support à long terme.
Ces paquets ont été mis à disposition progressivement, et non tous en même temps. À mesure que chaque version arrivait sur notre miroir de paquets, notre équipe d’ingénieurs la validait et commençait son déploiement sans attendre que toutes les branches PHP soient prêtes.
Voici comment s’est déroulé le déploiement :
| Date et heure (UTC) | Ce qui s’est passé |
| 21 octobre, environ 14 h 00 – 17 h 45 | PHP a publié les correctifs de sécurité. PHP 8.5.12 est devenu disponible sur notre miroir de paquets à 14 h 24, et le déploiement a commencé à 15 h 54. À 17 h 45, des dizaines de milliers de conteneurs avaient été mis à jour. |
| 21 octobre, 18 h 50 – 19 h 04 | PHP 8.3.36 a été mis à disposition, et son déploiement a commencé en parallèle de celui de PHP 8.5. |
| 21 octobre, de 21 h 17 à 22 h 28 | Des paquets corrigés pour PHP 7.4, 8.0 et 8.1 ont été mis à disposition, et de nouveaux déploiements ont commencé à 22 h 28. |
| 21–22 octobre, 23 h 25 – 1 h 37 | Les paquets PHP 8.2 et 8.4 sont arrivés à 23 h 25, et leur déploiement a commencé à 01 h 37 le 22 octobre. |
| 22 octobre, 04 h 31 | Il ne restait plus que 1888 conteneurs, soit environ 0,5 % du total, à mettre à jour et nécessitant une attention particulière. |
| 22 octobre, 08 h 26 | Nous avons confirmé une couverture de protection à 100 % et avons classé l’incident comme résolu. |
La capacité à déployer des modifications à cette échelle a constitué l’un des aspects les plus importants de l’intervention.
Farkas a souligné la rapidité avec laquelle l’équipe a pu déployer les modifications sur l’ensemble de l’infrastructure :
« C’est ce dont je suis le plus fier. Une fois qu’un changement est validé et que nous savons qu’il ne causera aucun dysfonctionnement, nous pouvons le déployer sur l’ensemble de l’infrastructure en l’espace de quelques heures. »
Cette capacité a permis à notre équipe de déployer des paquets PHP corrigés sur des centaines de milliers de conteneurs en quelques heures.
Nous n’avons pas non plus eu à coordonner les mises à jour PHP avec chaque client individuellement. Kinsta gère PHP au niveau de la plateforme ; ainsi, dès que l’équipe d’ingénierie a validé un paquet mis à jour, nous avons pu le déployer sur tous les environnements concernés sans demander aux propriétaires de sites d’installer eux-mêmes les mises à jour.
Pourquoi les anciennes versions de PHP nécessitaient-elles des correctifs supplémentaires ?
Le déploiement a également dû tenir compte de la différence entre les branches officiellement prises en charge par PHP et les anciennes versions maintenues par des fournisseurs tiers.
Le projet PHP a publié des mises à jour de sécurité pour les versions PHP 8.2 à 8.5. Des versions telles que PHP 7.4, 8.0 et 8.1 ne recevaient plus de mises à jour de sécurité régulières directement de la part du projet PHP, bien que les fournisseurs de support à long terme puissent proposer des correctifs rétroportés.
Le portage permet aux responsables de maintenance d’appliquer des correctifs de sécurité à une branche logicielle plus ancienne sans que les utilisateurs aient à passer à une version plus récente de PHP.
Cela signifiait que nous pouvions déployer des mises à jour de sécurité pour ces environnements PHP plus anciens à mesure que Freexian publiait des paquets corrigés.
Cela explique également pourquoi le numéro de version de PHP à lui seul ne permet pas toujours de savoir si un correctif de sécurité particulier a été appliqué. Les paquets gérés par les éditeurs peuvent inclure du code corrigé sans afficher le même numéro de version que la version officielle en amont de PHP.
Tout au long du déploiement, nous avons continué à mettre en place les mises à jour tout en maintenant les protections supplémentaires au niveau du pare-feu et de la configuration.
Surveillance des attaques et recherche de signes de compromission
Le déploiement des correctifs ne constituait qu’une partie de la réponse. Notre équipe devait également déterminer si les tentatives d’exploitation observées avaient abouti.
Lorsque nous avons remarqué pour la première fois une activité ciblant les sites web hébergés par Kinsta aux premières heures du 21 octobre, nos ingénieurs ont examiné manuellement les sites concernés.
Ils ont continué à surveiller le trafic suspect et à effectuer des contrôles ponctuels des environnements d’hébergement tout au long de l’incident, à la recherche d’indices indiquant que les attaquants avaient réussi à exploiter les vulnérabilités.
Les évènements de sécurité de Cloudflare nous ont aidés à comprendre ce qui était ciblé et comment les schémas d’attaque évoluaient à mesure que nous publiions de nouvelles règles. Cependant, le nombre de requêtes bloquées ne suffisait pas à lui seul à nous indiquer si des attaques avaient abouti.
C’est pourquoi les vérifications manuelles étaient essentielles. Notre équipe est également restée en contact étroit avec Patchstack, notre partenaire en matière de protection contre les vulnérabilités, afin de partager les informations relatives aux menaces et aux schémas d’attaque observés par les deux équipes. Nous avons également participé à des discussions avec d’autres hébergeurs afin d’échanger des informations et des bonnes pratiques, à mesure que la communauté PHP dans son ensemble réagissait.
Ces efforts sont venus compléter notre collaboration avec Cloudflare et Freexian. Cloudflare a fourni des protections contre les tentatives d’exploitation, Freexian a fourni les paquets PHP corrigés, et la coordination avec nos partenaires de sécurité a aidé nos ingénieurs à comprendre comment la menace évoluait.
Tout au long de l’incident, nous n’avons trouvé aucune preuve de compromissions réussies liées à PHP2Shell.
Cette conclusion repose sur la surveillance et les enquêtes menées pendant l’intervention. Cela ne signifie pas qu’il n’y a pas eu d’attaques, comme le montrent les données du pare-feu. Cela signifie que nos vérifications n’ont pas identifié de signes de compromission réussie.
Résolution de l’incident et poursuite de la vérification
Le 22 octobre à 08 h 26 UTC, nous avons indiqué sur notre page d’état publique que l’incident de sécurité PHP était résolu.
À ce moment-là, nous avions déployé des mises à jour de sécurité sur l’ensemble de la plateforme, et tous les sites étaient protégés par des mesures combinées de correction et d’atténuation.
La résolution de l’incident ne signifiait pas pour autant que nous avions cessé nos vérifications. Notre équipe a continué à vérifier les environnements et à surveiller les protections après la clôture de l’incident public.
Cela s’est avéré crucial lors d’un déploiement impliquant plusieurs branches PHP et des centaines de milliers de conteneurs. À 04 h 31 UTC, environ 0,5 % des conteneurs nécessitaient encore une attention particulière. Nos ingénieurs ont continué à traiter ces environnements restants et à vérifier les résultats, plutôt que de considérer la disponibilité d’un paquet corrigé comme la preuve que chaque installation avait été mise à jour.
Les règles Cloudflare et les mesures de protection de la configuration PHP sont également restées en place pendant ce travail de vérification.
Pour les clients, les mises à jour de sécurité PHP n’ont nécessité aucun correctif manuel ni changement de version.
Réponse aux clients ayant pris des précautions supplémentaires
La réaction face à PHP2Shell s’est étendue bien au-delà des hébergeurs. À mesure que la nouvelle des vulnérabilités se propageait, des agences gouvernementales et d’autres organisations du monde entier ont commencé à mettre temporairement leurs sites web hors ligne tout en préparant des mises à jour de sécurité.
Aux Pays-Bas, le Centre national de cybersécurité a mis son propre site web hors ligne par mesure de précaution. Des sites web gouvernementaux en Allemagne, en France, en Belgique et en Finlande ont également été temporairement suspendus. Au Japon, la Première ministre Sanae Takaichi a publié un avertissement urgent sur X, exhortant les exploitants de sites web à appliquer les correctifs dès que possible ou à suspendre temporairement leurs services s’ils ne pouvaient pas effectuer la mise à jour immédiatement.
Chez Kinsta, nous avons constaté des préoccupations similaires chez nos clients. Notre équipe de support a enregistré une augmentation significative des questions concernant PHP2Shell, et certains clients ont commencé à prendre des précautions supplémentaires pour protéger leurs sites web.
Il s’agissait notamment d’utiliser la fonctionnalité de suspension d’environnement de MyKinsta pour mettre les sites hors ligne, d’activer les défis à l’échelle du site via Bot Protection, ou de demander au service d’assistance de bloquer le trafic entrant au niveau du serveur. Les clients ont suspendu de manière proactive environ 3000 sites pendant l’incident.
Compte tenu de la gravité des vulnérabilités et des précautions prises ailleurs, ces décisions étaient compréhensibles. Cependant, l’équipe d’ingénierie n’a pas recommandé aux clients de mettre hors ligne leurs sites web hébergés chez Kinsta. Nous avions déjà activé les règles WAF d’urgence de Cloudflare sur l’ensemble de notre plateforme d’hébergement ; ainsi, les sites restés en ligne ont continué à bénéficier de ces protections sans devenir inaccessibles aux visiteurs.
Notre équipe de support a commencé à déconseiller aux clients toute suspension inutile tandis que l’équipe d’ingénierie poursuivait le déploiement des correctifs PHP.
Une fois les mises à jour de sécurité déployées, nous avons examiné les mesures de suspension prises pendant l’incident afin d’identifier les sites web que les clients avaient mis hors ligne spécifiquement en raison de PHP2Shell.
Notre équipe a ensuite réactivé ces environnements tout en laissant intacts les sites suspendus pour des raisons sans rapport avec cet incident. Cela a nécessité de distinguer les suspensions préventives des autres suspensions intentionnelles, plutôt que de simplement rétablir tous les environnements qui avaient été mis hors ligne.
Au-delà du blocage des attaques et du déploiement des correctifs, nos équipes ont également dû aider les clients à se remettre des mesures de précaution qu’ils avaient prises pendant l’incident.
Ce que cette intervention a signifié pour les clients de Kinsta
PHP2Shell a nécessité une coordination entre les équipes d’ingénierie, de support et plusieurs partenaires externes spécialisés dans la sécurité et l’infrastructure. Mais la plateforme s’est chargée elle-même de l’application des correctifs.
Les clients n’ont pas eu à suivre la disponibilité de chaque version de PHP, à déterminer quel paquet corrigé leur site web nécessitait, ni à installer eux-mêmes les mises à jour.
Farkas a expliqué ce que cette intervention a finalement signifié pour les clients de Kinsta :
« Pour moi, le message principal est que les clients n’ont pas eu à se soucier de quoi que ce soit : quoi mettre à jour, quand ni comment. Ils étaient simplement protégés sur notre plateforme. »
La réaction des clients pendant l’incident a également montré pourquoi il était important de communiquer sur ces mesures de protection. Certains clients ont mis leurs sites web hors ligne alors même que les règles WAF d’urgence étaient déjà actives, et nos équipes ont ensuite travaillé à la restauration des environnements suspendus en raison des vulnérabilités.
Parallèlement, notre équipe d’ingénieurs a déployé les mises à jour de sécurité PHP sur des centaines de milliers de conteneurs sans que les clients aient à gérer ces changements.
Pour consulter le compte-rendu des mises à jour de sécurité et de la résolution de l’incident, veuillez vous reporter à notre rapport d’incident de sécurité PHP.
Pour obtenir des conseils sur les implications de ces vulnérabilités pour votre site web, veuillez consulter notre article complémentaire, « PHP2Shell : comment Kinsta a protégé les sites WordPress ».
Joel est un développeur d'interfaces publiques qui travaille chez Kinsta en tant que rédacteur technique. Il est un enseignant passionné par l'open source et a écrit plus de 200 articles techniques, principalement autour de JavaScript et de ses frameworks.
