Failles critiques de PHP : l'ANSSI fait couper les sites des préfectures et conseille d'en faire autant

Ce jeudi 22 octobre en fin de matinée, le site de la préfecture du Nord affiche toujours « Maintenance en cours », comme celui du Rhône. Depuis la veille, le ministère de l'Intérieur a coupé ses sites exposés à deux failles critiques de PHP, le langage qui fait tourner WordPress, Drupal, Magento et une bonne partie du Web. « À la demande de l'Agence nationale de la sécurité des systèmes d'information, le ministère de l'Intérieur a procédé à la mise en maintenance préventive de l'ensemble de ses sites internet exposés à une vulnérabilité critique de sécurité », a-t-il indiqué. Il ne s'agit pas d'une attaque, mais d'une précaution.

L'ANSSI conseille à tous d'en faire autant. Dans un message diffusé avec le CERT-FR, elle recommande, lorsque c'est possible, la mise hors ligne des serveurs concernés jusqu'à l'application de la mise à jour, en citant le risque de déni de service, de vol de données, de prise de contrôle du système d'information et d'interruption d'activité. Les deux failles, CVE-2026-109618 et CVE-2026-109619, sont notées 9,2 sur 10 (CVSS v4). Leurs détails avaient fuité avant le correctif : PHP a avancé sa publication d'un jour, et les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35 sont sorties le mercredi 21 octobre vers 16 h, heure de Paris.

Toutes les installations web de PHP sont concernées

Selon PHP, ces failles peuvent permettre à un attaquant sans compte d'exécuter du code sur le serveur. La première vient de la gestion du manque de mémoire : PHP peut être interrompu alors que les données de la requête ne sont qu'à moitié initialisées, et le nettoyage qui suit les traite comme valides. La seconde laisse survivre l'état interne d'une requête après la libération de sa mémoire : la requête suivante traitée par le même processus peut le réutiliser. Le défaut est dans PHP lui-même : un site au code irréprochable reste vulnérable.

PHP cite toutes les installations qui servent des pages web : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Le risque est le plus élevé avec mod_php, le module d'Apache : une seule requête, sans authentification, suffit à déclencher l'attaque avant même que le code de l'application ne s'exécute. L'ANSSI juge la situation particulièrement critique pour les sites transactionnels, ceux qui manipulent des données sensibles et ceux qui sont reliés à des systèmes internes.

Les vieilles versions de PHP n'auront pas de nouvelle version officielle

L'alerte du CERT-FR (CERTFR-2026-ALE-014) range parmi les versions touchées toutes les 5.x, 6.x, 7.x, 8.0 et 8.1, qui ne sont plus maintenues. Pour elles, il recommande d'isoler les serveurs, puis de migrer vers une version suivie. PHP a tout de même publié des correctifs minimaux, sous forme de code source, pour les branches 7.4, 8.0 et 8.1. Les distributions Linux et les éditeurs de support étendu ont reçu les correctifs à l'avance : c'est chez eux qu'il faut chercher les paquets à jour.

Que faire si la mise à jour doit attendre ?

Les préfectures ont choisi de fermer plutôt que de parier sur un contournement, et PHP leur donne raison : seule la mise à jour protège vraiment. Si vous ne pouvez ni mettre à jour ni couper, le CERT-FR propose deux mesures, qu'il n'a pas lui-même validées :

• Désactiver le suivi des envois de fichiers : session.upload_progress.enabled = Off dans le php.ini, et php_admin_flag[session.upload_progress.enabled] = off dans les pools PHP-FPM, puis redémarrer les processus. Cela ne réduit le risque que pour l'une des deux failles.
• Bloquer les requêtes HTTP de type multipart (celles des formulaires avec envoi de fichiers) sur le pare-feu applicatif, ou au moins les surveiller de près.
• Chercher des traces depuis le 17 octobre : Amazon dit avoir vu une première tentative ce jour-là sur ses serveurs pièges, quatre jours avant la publication. Amazon conseille de repérer les requêtes POST contenant PHP_SESSION_UPLOAD_PROGRESS, Huntress les processus PHP qui lancent un shell, curl ou wget. Selon The Hacker News, des erreurs de limite mémoire ou des réponses 500 en série, des cookies de session anormalement longs et des redémarrages inexpliqués des processus PHP doivent aussi alerter.

Des tentatives d'attaque, pas encore d'intrusion confirmée

Le 21 octobre, watchTowr a dit observer des tentatives d'exploitation des deux failles, et Cloudflare des « premières attaques ». Amazon estime désormais que les failles sont largement exploitées, sans savoir si ses tentatives observées auraient réussi sur de vrais serveurs. Au matin du 22 octobre, aucune des deux ne figure au catalogue des failles exploitées de la CISA. La France n'est pas seule à avoir coupé : aux Pays-Bas, DigiD, MijnOverheid et le centre national de cybersécurité lui-même ont été mis hors ligne. Ce jeudi matin, impots.gouv.fr et le site de la CNIL affichent encore une page de maintenance. Reste à savoir quand ces sites rouvriront, et combien de petits serveurs, sur des versions oubliées, resteront en ligne sans correctif.