Au Japon, les suspensions liées aux failles de sécurité de PHP touchent 1 090 services, qui peinent à rouvrir

Des centaines de services attendent toujours de rouvrir

La réponse du Japon à deux graves failles de sécurité de PHP a perturbé au moins 1 090 sites web et services en ligne. Au 26 octobre 2026, des centaines d’entre eux n’avaient toujours pas annoncé leur réouverture. Les perturbations touchent les achats en ligne, les démarches liées aux comptes financiers, les services de garde d’enfants et les jeux, tandis que les opérateurs installent des correctifs et vérifient si leurs systèmes peuvent être reconnectés en toute sécurité.

Assured, une entreprise tokyoïte qui fournit des informations sur l’évaluation de la sécurité des services cloud, a recensé 1 090 suspensions de services au 26 octobre à 15 h. Son analyse s’appuie principalement sur les publications annonçant des interruptions, diffusées par des comptes officiels sur X. Le total était passé de 502 à 14 h le 23 octobre, soit une hausse de 588 suspensions, ou d’environ 117 %, en trois jours environ.

Pour 465 de ces services, Assured n’avait pas confirmé l’annonce d’une réouverture. Cela représente environ 43 % des suspensions recensées. Les chiffres reposent sur les annonces publiques : il reste donc à confirmer auprès des opérateurs la situation actuelle de ces 465 services.

Bandai Namco Holdings prévoyait de rouvrir à midi le 27 octobre une boutique en ligne vendant des jouets et d’autres produits, après le début d’une opération de maintenance dans la soirée du 21 octobre. Les connexions en ligne de jeux d’arcade, dont Taiko no Tatsujin, restaient suspendues. Chez Daiwa Securities, certaines fonctions du site web étaient de nouveau accessibles, mais les demandes d’ouverture de comptes d’investissement NISA et des démarches telles que les changements d’adresse restaient indisponibles à 17 h le 26 octobre.

Les conséquences des failles PHP2shell

L’Agence japonaise pour la promotion des technologies de l’information, connue sous le sigle IPA, a identifié les vulnérabilités sous les références CVE-2026-109618 et CVE-2026-109619 dans son avis de sécurité sur PHP du 22 octobre. Leur combinaison est appelée PHP2shell. PHP est un logiciel utilisé pour faire fonctionner de nombreux sites web et applications web ; il traite les opérations sur les serveurs avant que les informations n’atteignent le navigateur de l’utilisateur.

CVE-2026-109618 concerne la gestion des erreurs lorsque PHP manque de mémoire. CVE-2026-109619 porte sur le traitement des requêtes envoyées à un serveur. L’exploitation de ces failles pourrait permettre à un attaquant distant d’exécuter du code arbitraire, c’est-à-dire des instructions choisies par l’attaquant plutôt que par l’opérateur du site web.

JPCERT/CC, l’organisme japonais chargé de la coordination des incidents de sécurité informatique, indique que ce code pourrait s’exécuter avec les autorisations du processus PHP. En clair, un attaquant pourrait effectuer les actions autorisées au logiciel qui fait fonctionner le site web. L’étendue de ses possibilités dépendrait des autorisations et de la configuration du système concerné.

L’IPA recommande aux organisations de consulter les informations des développeurs ou des fournisseurs des produits qu’elles utilisent, car PHP peut faire partie d’une application ou d’un service plus vaste. JPCERT/CC avertit également que les versions de PHP fournies avec des produits logiciels ou des distributions Linux peuvent être concernées : les recommandations des fournisseurs doivent donc faire partie de la réponse.

Comment les suspensions se sont étendues

Les opérateurs ont commencé à mettre des systèmes hors ligne le 21 octobre, avant la mise à disposition des mises à jour de sécurité, vers 23 h, heure japonaise. Certains ont pris les devants avant leur publication, alors que la divulgation d’informations sur les failles pouvait accroître le risque d’attaques.

La chronologie montre comment une mise à jour logicielle urgente a entraîné plusieurs jours de perturbations :

• 21 octobre : BASE, Codmon, Pixiv, DMM.com, niconico et certains services de Sakura Internet passent en maintenance ou suspendent certaines fonctions. Des jeux comme Granblue Fantasy et Uma Musume Pretty Derby sont également temporairement interrompus.
• 21 octobre, 21 h 55 : la Première ministre Sanae Takaichi appelle à se préparer de toute urgence à appliquer les correctifs et indique que la suspension temporaire des sites web est une option lorsque leur installation immédiate est difficile.
• 21 octobre, vers 23 h : les mises à jour de sécurité de PHP sont publiées.
• 22 octobre : l’IPA et JPCERT/CC publient des alertes expliquant les vulnérabilités et les mesures recommandées.
• 23 octobre : le décompte d’Assured atteint 502 suspensions. Les développeurs de PHP révèlent également une autre vulnérabilité, CVE-2026-115560.
• 26 octobre : le total d’Assured atteint 1 090, tandis que JPCERT/CC met à jour son avertissement en faisant état de tentatives d’exploitation.
• 27 octobre, midi : Bandai Namco prévoit de rouvrir sa boutique en ligne de jouets et d’autres produits.

Pourquoi la mise hors ligne des sites est devenue une option

Le Bureau national de cybersécurité du Japon a indiqué que la suspension temporaire d’un site web pouvait réduire les risques lorsque les opérateurs n’étaient pas en mesure d’installer rapidement le correctif. Takaichi a repris cette option dans son appel du 21 octobre. CERT-EU et le Centre national de cybersécurité britannique ont également appelé à agir et évoqué la mise hors ligne des systèmes jusqu’à la mise en place de protections comme une réponse possible.

Les recommandations de l’IPA présentent une série de mesures possibles. Les organisations doivent d’abord envisager des protections temporaires et des restrictions d’accès, le temps de préparer une mise à jour ou une migration. Si des mesures temporaires efficaces sont difficiles à mettre en œuvre, elles doivent évaluer la possibilité de bloquer les accès externes ou de suspendre le service, en tenant compte des dommages potentiels et des perturbations pour leurs activités.

Pour les clients, cette décision a signifié la perte d’accès à des services du quotidien pendant que les opérateurs intervenaient. Un site marchand pouvait cesser d’accepter les commandes, un site financier suspendre les démarches liées aux comptes et une borne d’arcade perdre sa connexion aux fonctions en ligne.

Yasuhiro Suzuki, qui a dirigé l’enquête d’Assured, a déclaré que les opérateurs choisissaient de plus en plus de suspendre leurs services pour protéger les informations des clients, tandis que la lenteur de leur rétablissement témoignait de la difficulté d’une réouverture en toute sécurité. Son analyse résume le principal problème opérationnel : couper les accès peut être rapide, mais leur rétablissement exige que les travaux de fond soient achevés.

Le correctif ne suffit pas à rouvrir un service

Les perturbations chez Bandai Namco montrent pourquoi les services d’un même groupe peuvent reprendre à des moments différents. Le groupe prévoyait de rouvrir sa boutique de produits dérivés le 27 octobre, tandis que les connexions des jeux d’arcade restaient suspendues. La mise à jour des systèmes nécessaires à l’installation du correctif PHP prenait du temps.

Certains services envisageaient également de transférer temporairement leurs données vers les serveurs d’une autre entreprise, dont la sécurité avait été vérifiée. Cela permettrait de changer l’environnement dans lequel fonctionne le service pendant que les équipes interviennent sur le système concerné, mais nécessiterait des préparatifs supplémentaires avant que les clients puissent y accéder de nouveau.

Daiwa Securities avait rétabli certaines parties de son site web, notamment les questions fréquentes, mais les demandes d’ouverture de compte et les changements d’adresse étaient toujours indisponibles le 26 octobre. Une page d’information fonctionnelle coexistait donc avec des démarches clients interrompues.

L’IPA explique que les systèmes qui n’ont pas été mis à jour depuis longtemps peuvent nécessiter des modifications du code des applications et des vérifications pour s’assurer que leurs fonctions restent opérationnelles après la mise à jour de PHP. L’absence de documentation de développement, de personnel connaissant le système ou de contrats de maintenance en cours peut compliquer les opérations. JPCERT/CC recommande d’effectuer suffisamment de tests, puis d’installer rapidement les versions corrigées.

Quelles versions nécessitent une intervention ?

L’IPA et JPCERT/CC recensent quatre versions corrigées pour les deux premières vulnérabilités : PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12. Les versions antérieures de chacune de ces branches sont concernées. Les opérateurs doivent choisir le correctif correspondant à la branche PHP utilisée par leur système et consulter les recommandations de leur fournisseur de logiciels ou de système d’exploitation.

Les installations plus anciennes posent un problème supplémentaire. L’IPA cite les conclusions de l’entreprise de sécurité Wiz, selon lesquelles les versions à partir de PHP 5.4 sont concernées par au moins l’une des deux vulnérabilités. PHP 8.1 et les versions antérieures ne sont plus prises en charge et ne bénéficient donc plus de la maintenance normalement assurée pour les versions supportées.

L’IPA recommande de passer à des versions de PHP prises en charge ou à des produits et services dotés de protections lorsque aucun correctif n’est disponible. JPCERT/CC ajoute que les développeurs de PHP ont proposé des mesures d’atténuation limitées pour PHP 7.4, 8.0 et 8.1, compte tenu de la gravité des vulnérabilités.

Les mesures d’atténuation temporaires réduisent l’exposition à certaines voies d’attaque. Selon JPCERT/CC, la mise à jour est le remède aux vulnérabilités initiales : les organisations qui appliquent des paramètres temporaires doivent donc toujours prévoir la mise à jour logicielle ou la migration nécessaire pour leurs systèmes.

Les tentatives d’attaque renforcent l’urgence

Dans la mise à jour publiée le 26 octobre de son avis sur les vulnérabilités de PHP, JPCERT/CC indique que de nombreux exemples de code présentés comme capables d’exploiter les failles ont été publiés. L’organisme fait également état de signalements répétés de trafic réseau visant à exploiter ces vulnérabilités.

La réussite de ces codes dépend notamment de la version de PHP, de l’environnement d’exécution et de la disposition des données en mémoire. JPCERT/CC avertit que d’autres méthodes d’attaque et techniques ciblant des environnements particuliers pourraient apparaître et recommande à la fois de mettre à jour les systèmes et de rechercher d’éventuelles compromissions.

Ses recommandations d’investigation incluent la recherche de cookies PHPSESSID anormalement longs ou dont le format est inhabituel. Ces cookies contiennent des informations permettant de reconnaître la session d’un navigateur. Parmi les autres signes d’alerte figurent des requêtes suspectes utilisant le format multipart/form-data, couramment employé pour les téléversements, notamment lorsqu’elles surviennent à proximité d’erreurs de limite mémoire ou d’erreurs HTTP 500 indiquant un problème côté serveur.

Les plantages inattendus ou les redémarrages fréquents des processus PHP worker constituent un autre point à examiner. Ces processus traitent les tâches entrantes. JPCERT/CC recommande également de rechercher des processus suspects, des communications externes et des fichiers récemment créés, et de poursuivre la surveillance. En cas de suspicion de compromission, l’organisme conseille de préserver les journaux et les autres éléments de preuve, d’examiner la zone touchée et d’isoler les systèmes si nécessaire.

Une troisième vulnérabilité exige de modifier un paramètre

Les développeurs de PHP ont révélé CVE-2026-115560 le 23 octobre, ajoutant une nouvelle tâche aux opérations en cours. JPCERT/CC indique que cette vulnérabilité peut permettre l’exécution de code arbitraire lorsque certains paramètres de configuration sont associés à un code applicatif particulier.

Les développeurs ont précisé que la configuration concernée était peu courante et prévu de publier un correctif dans le cadre du cycle habituel des mises à jour. D’ici là, JPCERT/CC a relayé la recommandation de définir session.upload_progress.enabled=0 et de redémarrer tous les processus worker. Sa mise à jour du 26 octobre n’indiquait aucune date de publication du correctif.

Ce même paramètre avait déjà été recommandé comme mesure d’atténuation pour CVE-2026-109619. Selon l’avis, les opérateurs qui l’avaient appliqué n’avaient pas à répéter cette étape de configuration. Les équipes doivent néanmoins tenir compte des deux premières vulnérabilités et de ce problème supplémentaire lorsqu’elles vérifient leurs systèmes.

Certaines organisations doivent prendre une décision plus large

Les recommandations de l’IPA vont au-delà de la réparation immédiate. L’agence demande aux organisations d’examiner le rôle que joue encore un système, son niveau d’utilisation et la possibilité de le remplacer par un autre service. Pour les logiciels qui n’ont pas été entretenus, le rétablissement du service peut aussi nécessiter de décider qui en assurera la maintenance par la suite.

L’IPA indique que les responsables d’entreprise et les dirigeants, au même titre que les équipes techniques, doivent évaluer s’ils disposent des ressources humaines, du budget et des dispositifs de maintenance nécessaires à une mise à jour ou à une migration, ainsi qu’au maintien du service. Si ces moyens sont disponibles, l’agence recommande d’effectuer la mise à jour ou de passer à un service protégé.

Si la maintenance ne peut pas être assurée dans la durée, l’IPA propose d’autres options : passer à un produit bénéficiant d’une assistance, réduire les fonctionnalités, mettre fin à l’accès public ou retirer le système. L’agence appelle également à prévoir la conservation ou le transfert des données nécessaires et à expliquer aux utilisateurs les solutions de remplacement.

Le défi concret va désormais de l’installation de versions précises de PHP au rétablissement des différentes fonctions utilisées par les clients. La réouverture prévue de la boutique de Bandai Namco constitue une première échéance, tandis que les 465 services pour lesquels Assured n’avait pas confirmé d’annonce de réouverture montrent l’ampleur des vérifications de statut qui restaient à effectuer le 26 octobre.

À retenir

• Au Japon, Assured a recensé 1 090 suspensions de services au 26 octobre à 15 h, contre 502 le 23 octobre.
• Aucune annonce de réouverture n’avait été confirmée pour 465 services, soit environ 43 % du total.
• Les vulnérabilités PHP2shell peuvent permettre à des attaquants distants d’exécuter du code avec les autorisations du processus PHP.
• Les versions corrigées pour les deux premières failles sont PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12.
• JPCERT/CC a alerté sur la publication d’exemples de code et sur des signalements de tentatives d’exploitation.
• Une troisième vulnérabilité nécessite une modification temporaire de la configuration et le redémarrage de tous les processus worker en attendant la préparation d’un correctif.
• Bandai Namco prévoyait de rouvrir sa boutique de produits dérivés le 27 octobre à midi ; certaines connexions de jeux d’arcade et les démarches de Daiwa Securities restaient suspendues le 26 octobre.