L'équipe de sécurité de PHP a publié aujourd'hui, 21 octobre, un correctif pour deux vulnérabilités, toutes deux notées 9,2 sur 10. Il était prévu à 10 h (heure de l'Est des États-Unis) et il est sorti en avance.
Les chercheurs en sécurité appellent la paire PHP2Shell. Leurs noms officiels sont CVE-2026-109618 et CVE-2026-109619.
Si votre site web tourne sous WordPress ou Drupal, il tourne sous PHP.
Mise à jour, 9 h 36 (heure de l'Est des États-Unis) : le correctif est sorti
PHP a publié le correctif en avance. Nous l'avons vu sur php.net à 9 h 36 (heure de l'Est des États-Unis).
Passez à PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35. PHP 8.1 et les versions antérieures ne reçoivent pas de mise à jour du projet PHP. Certaines distributions Linux et certains prestataires de support reportent le correctif : renseignez-vous auprès du vôtre, ou passez à une version maintenue.
Avec la version, PHP a publié ce qu'est vraiment le problème. En termes simples :
- Les deux failles se trouvent dans la façon dont PHP prépare et nettoie chaque requête web. L'une survient quand PHP manque de mémoire en pleine préparation d'une requête : le nettoyage peut alors traiter des données à moitié construites comme valides. L'autre laisse derrière elle les données d'une requête après la libération de leur mémoire, et la requête suivante sur le même processus peut les utiliser.
- L'une ou l'autre peut permettre à un inconnu d'exécuter son propre code sur votre serveur, sans se connecter, en envoyant des requêtes conçues pour cela.
- Elles touchent PHP quand il sert des pages web : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. PHP indique que le risque est le plus élevé avec mod_php d'Apache, pour lequel une attaque fonctionne.
- Elles se produisent avant que le code de votre site ne s'exécute. Une extension de sécurité dans WordPress ou Drupal ne peut donc pas les voir. Ce qui vous protège, c'est la mise à jour, et des limites appliquées devant PHP.
PHP liste aussi des réglages qui réduisent l'exposition si vous ne pouvez pas mettre à jour tout de suite, et précise qu'ils ne rendent pas un serveur sûr. Ils figurent dans l'avis sur php.net.
Pourquoi LFW.com n'a jamais été exposé : ces failles se trouvent dans le code qui s'exécute quand PHP traite une requête. Les pages de LFW.com sont des fichiers construits à l'avance, et aucun PHP ne lit de requête sur nos serveurs : il n'y a rien à déclencher. Les copies en lecture seule publiées ce matin par les gouvernements européens sont sûres pour la même raison.
Si vous avez mis un site hors ligne, il peut revenir dès que votre hébergeur confirme qu'il tourne sur l'une des versions corrigées.
Ce que nous avons vérifié sur nos propres serveurs
Nous avons commencé ce matin par notre propre installation.
- LFW.com : pas concerné. Il est construit avec Astro et servi par Node.js, et aucun PHP n'est installé sur nos serveurs.
- Une démo WordPress : nous avons trouvé une démo WordPress conteneurisée que nous avions arrêtée il y a environ trois semaines sans jamais la retirer. Elle ne tournait pas et elle était protégée par un mot de passe. Nous l'avons retirée quand même, avec sa base de données et ses images.
- Nos machines de développement : les copies locales de WordPress que nous utilisons pour le développement sont arrêtées, et aucune n'est accessible depuis internet.
C'est la démo qui mérite d'être racontée. Elle n'avait aucun problème aujourd'hui. C'était simplement un site sous PHP dont nous n'avions plus besoin, et il était toujours là.
Le site dont personne ne se souvient
Un jour comme celui-ci, le site principal est en général mis à jour. Quelqu'un en est responsable, et quelqu'un le surveille.
Le risque se trouve plus souvent dans un site que personne ne se souvient d'avoir :
- le microsite d'une campagne terminée
- la copie de préproduction qu'un prestataire a montée pour une refonte
- le site d'un événement d'il y a quelques années
- une démo ou une installation de test jamais retirée
Ces sites tournent toujours sous PHP, et personne n'attend la mise à jour.
Ce que nous ferions aujourd'hui
Dans cet ordre :
- Commencez par votre hébergeur. Avec un hébergement géré, consultez sa page d'état ou son blog. Un jour comme celui-ci, la plupart publient leur plan, et beaucoup mettent PHP à jour pour vous : vous n'aurez peut-être pas besoin de les contacter.
- Listez chaque site qui tourne sous PHP. Y compris les oubliés. Retirez ceux que vous n'utilisez pas.
- Mettez à jour les autres le jour même du correctif. Demandez à la personne qui gère chaque site de vous prévenir quand c'est fait.
- Gardez un pare-feu devant d'ici là. Un pare-feu applicatif web n'aide que si le serveur refuse le trafic qui ne passe pas par lui : vérifiez aussi ce réglage.
Arrêter le serveur
Le Centre national de cybersécurité du Royaume-Uni dit que si vous ne pouvez ni mettre à jour ni appliquer les solutions temporaires de PHP, il faut envisager de mettre le système hors ligne en attendant. Vu la gravité signalée, ce n'est pas un mauvais conseil, même s'il peut sembler excessif.
Arrêter le serveur ne veut pas forcément dire arrêter le site. Vous pouvez publier entre-temps une copie en lecture seule : des pages statiques, sans PHP derrière.
- Les habitants peuvent toujours lire les pages et trouver les numéros de téléphone.
- Les formulaires, les connexions et les recherches attendent la mise à jour.
- La copie est retirée quand le site mis à jour revient.
Pour un site public sur lequel les gens comptent, c'est un meilleur compromis qu'une page blanche.
Des gouvernements ont mis des sites hors ligne ce matin
Plusieurs gouvernements ont jugé que quelques heures hors ligne en valaient la peine.
Voici ce que nous avons vu à 8 h 50 (heure de l'Est des États-Unis) :
- Le Centre national de cybersécurité des Pays-Bas a mis son propre site, NCSC.nl, hors ligne par précaution.
- DigiD et MijnOverheid, l'accès du gouvernement néerlandais et son portail pour les citoyens, affichaient des pages « temporairement indisponible ».
- L'Université de Vienne a coupé ses sites web, ses formulaires en ligne, sa messagerie web et Moodle.
- Le site de la Chambre des représentants néerlandaise ne s'est pas chargé du tout chez nous. NL Times a indiqué qu'il avait lui aussi été mis hors ligne.
- Le centre informatique du gouvernement finlandais, Valtori, a coupé par précaution le trafic internet entrant vers les services publics de l'État, et l'a expliqué sur son site. Il a précisé que la coupure n'était pas due à une attaque.
Il n'y a aucune honte à cela. Ce sont quelques heures, et le problème est assez grave pour que l'agence dont le métier est la cybersécurité l'ait choisi pour son propre site.
Ce que les agences de cybersécurité ont demandé
Ce n'était pas seulement l'Europe. Des agences nationales de cybersécurité sur trois continents ont publié des alertes le même jour, et elles s'accordent pour l'essentiel :
- Royaume-Uni : le Centre national de cybersécurité demande de trouver tous les systèmes qui font tourner PHP, de mettre à jour et d'envisager la mise hors ligne si c'est impossible.
- Union européenne : le CERT-EU, qui protège les institutions de l'UE elles-mêmes, a conseillé d'isoler les applications exposées à internet quand la mise à jour ne peut pas se faire tout de suite.
- Singapour : l'Agence de cybersécurité demande de mettre à jour immédiatement et de chercher PHP sur chaque serveur web, même là où le site principal ne l'utilise pas.
- Australie : le Centre australien de cybersécurité a invité les organisations à repérer PHP dans leur environnement, à se préparer à mettre à jour et à surveiller les signes d'attaque.
C'est le point de Singapour que nous soulignerions. Un site construit avec autre chose peut quand même avoir PHP sur le même serveur : un vieil outil d'administration, une installation oubliée, un module d'un prestataire.
Ce que leurs pages hors ligne ont bien fait
Regardez bien ces pages. Elles ne sont pas vides, et ce ne sont pas des messages d'erreur.
- Elles disent pourquoi. Chacune nomme les vulnérabilités PHP comme raison.
- Elles disent ce qui est coupé. Vienne liste chaque service, pour que personne n'ait à deviner.
- Elles disent où aller. Le NCSC renvoie vers son site d'avis, LinkedIn et une adresse e-mail joignable 24 h sur 24 pour l'aide urgente.
- Ce sont des pages statiques. Elles n'ont pas besoin de PHP pour s'afficher, c'est pourquoi elles sont toujours en ligne.
Ce dernier point, c'est toute l'idée de la copie en lecture seule. Ces pages en sont la plus petite version.
Écrivez cette page avant d'en avoir besoin
Rien de tout cela n'est difficile un jour calme. C'est difficile à 6 h du matin le jour d'une version de sécurité.
Quelques décisions méritent donc d'être prises maintenant, pendant que tout va bien :
- Qui peut mettre le site hors ligne, et qui il prévient. Un nom, et un suppléant.
- La page hors ligne elle-même, rédigée et stockée quelque part qui ne tourne pas sous PHP : la raison, ce qui est coupé, où suivre les nouvelles et comment joindre une personne.
- Quelles pages ne doivent jamais s'éteindre. Avis d'urgence, avis de faire bouillir l'eau, numéros de téléphone. Elles vont dans la copie en lecture seule.
- Comment vous saurez qu'il est sûr de revenir. En général : votre hébergeur confirme la version corrigée, et vous vérifiez une page vous-même.
Quelques heures hors ligne, prévues, c'est une bonne journée. Imprévues, c'est une affaire.
Si vous voulez un coup de main
Nous vous aidons volontiers pour chacune de ces étapes, qu'il s'agisse de retrouver les sites oubliés ou de publier une copie en lecture seule. Écrivez-nous.
Leland Fiegel