Des correctifs d’urgence ciblent deux failles d’un logiciel web très répandu
Le 21 octobre 2026, l’Agence sud-coréenne pour l’Internet et la sécurité (KISA) a exhorté les responsables de sites web à mettre PHP à jour, après la découverte de deux failles de sécurité dans ce logiciel utilisé pour gérer les pages de connexion, les services d’achat en ligne et les forums. Parmi les risques signalés figure la possibilité, pour des attaquants, d’exécuter du code sur un serveur sans s’y connecter au préalable.
Sommaire
- Des correctifs d’urgence ciblent deux failles d’un logiciel web très répandu
- Quelles versions de PHP sont concernées ?
- Ce que ces deux failles pourraient permettre
- Pourquoi WordPress concerne aussi les entreprises ordinaires
- La Corée du Sud mobilise deux réseaux de sécurité pour alerter les entreprises
- Comment la réponse s’est mise en place
- Détection par l’IA et recherches indépendantes en cybersécurité
- Pourquoi certaines autorités ont conseillé de mettre les sites hors ligne
- Ce que les responsables de sites doivent faire maintenant
- À retenir
La KISA a identifié ces vulnérabilités sous les références CVE-2026-109618, liée à une mauvaise gestion des situations exceptionnelles, et CVE-2026-109619, liée à l’utilisation de mémoire après sa libération. Les versions à installer concernent quatre branches de PHP : 8.2.35, 8.3.36, 8.4.27 et 8.5.12.
Dans la soirée du 21 octobre, le ministère sud-coréen des Sciences et des TIC et la KISA ont adressé des demandes de mise à jour aux entreprises et aux institutions appartenant aux réseaux nationaux de cybersécurité. Les autorités ont fait état de cette démarche le 22 octobre. Une aide d’urgence à l’installation des correctifs pour les petites entreprises était à l’étude.
Ces failles, désignées collectivement sous le nom de PHP2Shell, ont suscité une réponse internationale. Certaines institutions gouvernementales aux Pays-Bas et en Finlande auraient suspendu leurs sites par précaution, tandis que des autorités de cybersécurité en Europe, au Japon et en Australie ont appelé à installer les mises à jour. Des agences américaines auraient également conseillé de mettre hors ligne les systèmes concernés lorsqu’il était impossible d’appliquer immédiatement les correctifs.
Quelles versions de PHP sont concernées ?
Les recommandations de la KISA fixent une version minimale différente pour chaque branche de PHP concernée. Une branche regroupe plusieurs versions : un site utilisant PHP 8.3, par exemple, doit passer à la version corrigée de cette branche ou à une version plus récente, prise en charge.
- PHP 8.2 : mettre à jour les versions antérieures à 8.2.35.
- PHP 8.3 : mettre à jour les versions antérieures à 8.3.36.
- PHP 8.4 : mettre à jour les versions antérieures à 8.4.27.
- PHP 8.5 : mettre à jour les versions antérieures à 8.5.12.
La KISA a également averti que PHP 8.1 et les versions antérieures n’étaient plus officiellement prises en charge pour les mises à jour de sécurité. Il a été conseillé aux responsables qui utilisent ces versions de passer à une version prise en charge, plutôt que de continuer à utiliser un logiciel qui ne bénéficie plus de maintenance de sécurité officielle.
Pour une entreprise, la première démarche consiste à vérifier la version de PHP installée sur le serveur du site. Le logiciel peut être géré par l’hébergeur ou par l’équipe informatique interne. Mettre à jour le navigateur d’un ordinateur portable ne modifie pas cette partie du système.
Ce que ces deux failles pourraient permettre
La CVE-2026-109618 concerne les situations exceptionnelles, c’est-à-dire les cas où un logiciel rencontre un événement qui sort de son fonctionnement normal. Les programmes doivent être conçus pour les gérer de manière sûre. Une défaillance à ce niveau peut entraîner un comportement inattendu du logiciel.
La CVE-2026-109619 est décrite comme une vulnérabilité d’utilisation après libération. Les logiciels réservent temporairement des zones de mémoire vive, puis les libèrent lorsqu’ils n’en ont plus besoin. Ce type de faille survient lorsqu’un programme tente ensuite d’utiliser une zone déjà libérée, et risque ainsi d’accéder à des données qui ont changé ou qui appartiennent à une autre opération.
Le risque signalé est l’exécution de code à distance sans authentification. En clair, une personne extérieure pourrait potentiellement faire exécuter des instructions par le serveur d’un site web sans fournir de nom d’utilisateur ou de mot de passe valide. Une attaque réussie pourrait exposer des informations, installer un logiciel malveillant ou interrompre des services.
Les annonces publiques ne précisaient pas les configurations de serveur ni les conditions de requête exactes nécessaires pour exploiter chacune des failles. Les responsables doivent donc vérifier les versions des logiciels concernés et obtenir des conseils techniques adaptés à leur installation.
Pourquoi WordPress concerne aussi les entreprises ordinaires
PHP fonctionne sur le serveur d’un site web, et non sur le téléphone ou l’ordinateur de son visiteur. Lorsqu’un client souhaite consulter l’historique de ses commandes, un programme PHP peut récupérer les données pertinentes dans une base de données et préparer la page qui sera renvoyée au navigateur. Les systèmes de connexion, les commentaires et les forums fonctionnent de la même manière.
WordPress, qui propose des outils pour créer et gérer des sites web, fonctionne lui aussi avec PHP. La réponse à ces failles concerne donc les blogs, les sites d’entreprise et les boutiques en ligne, dont les propriétaires n’ont parfois que peu de contacts directs avec le langage de programmation sous-jacent.
Selon les chiffres du service de mesure des technologies web W3Techs, PHP est utilisé par environ 75 % des sites dont le langage de programmation côté serveur peut être identifié. WordPress représente environ 43 % de l’ensemble des sites web. Le chiffre concernant PHP porte sur un périmètre plus restreint que celui de WordPress : les sites dont le langage côté serveur est identifiable, et non la totalité des sites web.
Ces chiffres expliquent l’ampleur de la réponse. De nombreux sites exploités de manière indépendante reposent sur le même logiciel sous-jacent : une campagne de correctifs peut donc concerner simultanément des institutions publiques, de grandes entreprises et de petites sociétés.
La Corée du Sud mobilise deux réseaux de sécurité pour alerter les entreprises
Le ministère des Sciences et des TIC et la KISA ont adressé leurs demandes du 21 octobre aux membres de C-TAS, un système d’analyse et de partage des informations sur les cybermenaces, ainsi qu’aux entreprises tenues de désigner un responsable de la sécurité des systèmes d’information (CISO).
C-TAS compte environ 5 900 entreprises et institutions participantes. Environ 30 000 entreprises sont tenues, en vertu de la législation sud-coréenne sur les réseaux d’information et de communication, de désigner un CISO et d’en informer le ministère. Le CISO est le cadre supérieur chargé de la sécurité de l’information d’une organisation.
Ces deux chiffres correspondent à des groupes distincts, qui peuvent se recouper. Le gouvernement a également utilisé le portail public de cybersécurité de la KISA, appelé Boho Nara, pour recommander l’installation des mises à jour de sécurité et des correctifs.
Les petites entreprises font face à une difficulté très concrète : certaines n’ont pas de salariés capables de repérer une installation concernée, d’organiser une mise à jour et de vérifier ensuite que le site fonctionne toujours. Un responsable du ministère a indiqué que le gouvernement avait d’abord diffusé des consignes de sécurité et envisageait une aide d’urgence à l’installation des correctifs. Aucune date de lancement ni condition d’éligibilité n’a été annoncée.
Comment la réponse s’est mise en place
La chronologie rapportée remonte à un audit de sécurité externe mené en 2024 et aboutit à la publication accélérée de correctifs en octobre 2026. Les principales dates sont les suivantes :
- 2024 : un audit externe aurait révélé des signes de certaines failles. Des désaccords internes et des inquiétudes concernant la compatibilité avec les logiciels existants auraient empêché le développement de correctifs à cette période.
- 21 octobre 2026 : les développeurs de PHP auraient publié des correctifs pour deux vulnérabilités, et la KISA aurait recommandé une mise à jour.
- Dans la soirée du 21 octobre : les autorités sud-coréennes ont transmis leurs demandes de sécurité par l’intermédiaire de réseaux d’entreprises et d’institutions.
- 22 octobre : les autorités sud-coréennes ont décrit cette démarche. C’était également la date initialement prévue pour la publication des correctifs.
La publication des correctifs aurait été avancée d’un jour après la fuite d’informations sur les vulnérabilités. Des tentatives d’attaque auraient également été détectées avant la publication des correctifs, ce qui a accentué la pression sur les responsables de sites pour qu’ils agissent rapidement.
Le récit de l’audit de 2024 met aussi en lumière les difficultés liées à la maintenance. La modification d’un logiciel partagé peut avoir des conséquences sur les applications conçues en fonction de son comportement existant. Les problèmes de compatibilité compliquent la coordination des réparations, en particulier lorsqu’un langage alimente de nombreux sites et configurations d’hébergement différents.
Détection par l’IA et recherches indépendantes en cybersécurité
L’entreprise de cybersécurité Calif aurait découvert les vulnérabilités à l’aide d’un modèle d’OpenAI présenté comme GPT-5.6 Sol. Les failles auraient échappé à la détection pendant plus de dix ans.
Wiz, une entreprise de cybersécurité liée à Google, aurait découvert et signalé indépendamment les deux vulnérabilités. Ami Luttwak, cofondateur de Wiz, les a qualifiées de plus graves failles découvertes grâce à l’IA et a estimé que leur complexité les aurait rendues extrêmement difficiles à détecter sans cet outil.
OpenAI a indiqué avoir consacré les deux mois précédents à coordonner des chercheurs et des entreprises de cybersécurité afin de soutenir la réponse. L’entreprise a également prédit une forte hausse des découvertes similaires grâce à l’IA au cours des mois suivants.
Pour les responsables de sites, les tâches immédiates restent concrètes : identifier le logiciel installé, appliquer le correctif adapté et veiller au bon fonctionnement des services. Le recours à l’IA pour détecter les failles ajoute un nouvel élément au dossier, aux côtés des recherches indépendantes, de la coordination des développeurs et de la diffusion des correctifs.
Pourquoi certaines autorités ont conseillé de mettre les sites hors ligne
La National Security Agency américaine aurait exhorté les organisations utilisant PHP à procéder immédiatement aux mises à jour, avertissant que l’exploitation des failles pourrait donner aux attaquants accès au système de fichiers ou à la base de données d’un serveur. Elle a recommandé de mettre hors ligne les systèmes concernés jusqu’à la correction des failles si une mise à jour immédiate était impossible.
Le FBI aurait formulé des recommandations similaires, mettant en garde contre l’exécution de code à distance et le risque d’exposition d’informations et de réseaux sensibles. Certaines institutions gouvernementales néerlandaises et finlandaises ont suspendu leurs sites par mesure de précaution.
Mettre un site hors ligne a un coût immédiat : les visiteurs ne peuvent plus accéder aux services proposés. Pour une boutique, cela peut interrompre les ventes ; pour une institution publique, rendre indisponibles des informations ou des formulaires en ligne. Cette recommandation traduit la gravité du risque que représente un serveur vulnérable laissé accessible dans l’attente d’un correctif.
Cloudflare a indiqué qu’il adaptait ses mesures de protection aux méthodes d’attaque. Les responsables de sites ont néanmoins été invités à installer les correctifs de PHP afin de mettre le logiciel sous-jacent à l’une des versions indiquées dans le cadre de la réponse de sécurité.
Ce que les responsables de sites doivent faire maintenant
Les responsables de sites doivent déterminer qui gère leur installation de PHP et comparer sa version aux seuils indiqués par la KISA. Les organisations qui font appel à un hébergeur doivent lui demander de confirmer la version du serveur et les modalités de mise à jour. Les équipes qui gèrent leurs propres serveurs doivent effectuer elles-mêmes l’opération.
Les entreprises qui utilisent WordPress doivent inclure l’environnement d’exécution PHP dans leurs vérifications habituelles de maintenance du site. PHP est une couche logicielle distincte, sur laquelle repose le système de gestion de contenu : connaître uniquement la version de WordPress ne suffit donc pas pour vérifier l’ensemble de l’installation.
Les responsables qui utilisent PHP 8.1 ou une version antérieure doivent passer à une version prise en charge. Ceux qui utilisent déjà une branche concernée doivent installer la version corrigée correspondante ou une version plus récente adaptée et prise en charge. Tester les fonctions essentielles, comme la connexion des clients, la consultation des commandes et les paiements, permet de repérer d’éventuels problèmes de service pendant la mise à jour.
À retenir
- Le 21 octobre 2026, la KISA a recommandé une mise à jour de sécurité de PHP et signalé les vulnérabilités CVE-2026-109618 et CVE-2026-109619.
- Les versions minimales indiquées sont PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12.
- La KISA a conseillé aux utilisateurs de PHP 8.1 et des versions antérieures de passer à une version prise en charge.
- Les risques signalés comprennent l’exécution de code à distance par des attaquants sans connexion préalable.
- La Corée du Sud a contacté les membres de réseaux de sécurité et les entreprises tenues de désigner un CISO.
- Une aide d’urgence à l’installation des correctifs pour les petites entreprises sud-coréennes était à l’étude.
- Des autorités internationales ont appelé à installer les mises à jour ; certaines ont recommandé des mises hors ligne temporaires lorsqu’il était impossible d’appliquer immédiatement les correctifs.






