Vulnérabilités PHP : de nombreux sites Web déconnectés par précaution

Depuis hier, les correctifs des vulnérabilités référencées CVE-2026-109618 et CVE-2026-109619, et surnommées PHP2Shell, affectant toutes les versions de PHP, sont disponibles (mais uniquement pour les versions supportées). L’affaire est tellement grave que des Premiers ministres ont eux-mêmes alerté à leur sujet.

En France, Orange a annoncé la suspension temporaire de « l’accès à certains de ces services » afin « déployer les correctifs de sécurité nécessaires et de réaliser les vérifications associées avant la remise en service progressive des sites et applications ». Le cas est loin d’être isolé.

Plusieurs préfectures, Météo France, la CNIL, Santé Publique France, l’Ademe, et d’autres encore ont également fermé temporairement leurs sites Web.

À l’étranger, le service de l’emploi d’Andalousie a fait de même, ainsi que l’état de Neuchâtel, la ville d’Édinbourg, les gouvernements belge, danois, hongrois et letton, des universités à Berlin et dans le Brandenbourg, ou encore l’état de la Hesse et du Baden-Württenberg outre-Rhin, et la compagnie Pokémon, pour ne citer que quelques exemples.

Et il y a de quoi. Car selon l’équipe de renseignement sur les menaces d’Amazon, de premières tentatives d’exploitation de PHP2Shell ont été constatées le 17 octobre. Selon nos informations, des démonstrateurs d’exploitation réellement fonctionnels ont été développés. Mais ceux qui sont disponibles publiquement ne le seraient pas pleinement.

Le chercheur Daniel Card s’est penché sur les deux vulnérabilités et conclut qu’une exploitation fiable et en masse de PHP2Shell ressemble à un parcours d’obstacles. Selon lui, une huitaine de variables doivent s’aligner pour chaque cible. Dès lors, pour une bonne partie du Web, la menace se réduit au déni de service… et parfois à la fuite d’informations.

Car l’exploitation se joue en deux temps : un producteur, qui façonne l’état mémoire du serveur, et un consommateur, qui en profite, doivent tous deux atterrir sur le même worker, l’un de ces processus qui traitent les requêtes PHP. Mais dès qu’un répartiteur de charge ou un grand lot de workers s’en mêle, cette affinité devient une loterie. Et quand la fenêtre s’ouvre, elle se referme vite : plusieurs mécanismes sont susceptibles de remettre les compteurs à zéro.

À cela s’ajoute la façon dont PHP est accroché au serveur Web. Sous Apache avec mod_php, la chaîne complète est confirmée. Mais avec PHP-FPM (ou FastCGI Process Manager, le gestionnaire de processus PHP devenu la façon standard d’exécuter PHP sur le Web moderne) ou CGI, le scénario retombe au rang de simple déni de service : la requête productrice fait décrocher le worker dès le démarrage, avant d’amorcer quoi que ce soit. Ce seul critère retire déjà une large fraction de l’Internet de la colonne RCE (Remote Code Execution) pour le ranger dans la case déni de service.

Et puis il faut compter avec la limite de taille maximale d’une requête, l’architecture et la compilation, ou encore le gestionnaire de sessions.

Avec ces obstacles, toute tentative d’exploitation non réussie devient fortement bruyante, finissant en crash de worker, en erreurs 500, en processus qui se recyclent à haute vitesse avec, à la clé, des traces dans les journaux.