Deux failles critiques dans PHP ont coupé une partie du web : pourquoi les sites Alpesdata n'ont pas bougé

📌 Ce qui s'est passé, en clair

Mardi 20 octobre au soir, l'équipe de sécurité du projet PHP a publié une alerte inhabituelle : elle annonçait, sans en dire plus, une mise à jour de sécurité pour le lendemain. Les rumeurs parlaient de deux failles d'exécution de code à distance. Les correctifs sont sortis mercredi 21 octobre à 13h30 UTC (15h30 à Paris) — et le peu qu'on ignorait encore est devenu public en quelques minutes.

Il s'agit de deux vulnérabilités notées 9,2 sur 10 (CVSS v4.0, la catégorie critique), suivies sous les identifiants CVE-2026-109618 et CVE-2026-109619 et surnommées « PHP2Shell ». Les deux permettent à un attaquant non authentifié d'exécuter son propre code sur un serveur qui répond en PHP.

Dans l'après-midi, les conséquences sont devenues visibles : le CERT-FR a émis une alerte, l'Anssi a requis des opérations de maintenance, et des pans entiers de l'administration française — ministères, préfectures, impôts — sont devenus inaccessibles. L'agence estime à plus de 600 000 le nombre de serveurs utilisant PHP sur l'Internet français. La NSA américaine et le NCSC britannique ont, eux, recommandé de déconnecter les sites concernés tant qu'ils ne sont pas corrigés. Palo Alto Networks évalue à 22 millions le nombre de plateformes exposées.

Détail qui n'a rien d'anecdotique : selon OpenAI, les failles ont été trouvées par la société de sécurité Calif à l'aide de l'un de ses modèles les plus récents (GPT-5.6 Sol) ; Wiz (filiale de Google) dit les avoir identifiées de son côté. « Cela montre comment l'IA peut mettre au jour des brèches dont les conséquences concernent tout Internet », écrit OpenAI — en prévenant que ces mêmes capacités peuvent désormais aider des attaquants.

🧨 Pourquoi une faille dans PHP arrête des sites entiers

PHP est un langage côté serveur : c'est lui qui construit la page avant de l'envoyer au navigateur. WordPress, Joomla, Drupal, PrestaShop, Magento, Laravel, une bonne partie des outils de gestion de contenu et des boutiques en ligne s'appuient dessus. Wiz estime que PHP fait tourner environ 70 % du web mondial.

Une faille d'exécution de code à distance (RCE), c'est le pire scénario : l'attaquant ne se contente pas de lire une donnée mal protégée, il fait tourner ses propres programmes sur la machine. Ici, la faille est dans PHP lui-même, pas dans un module complémentaire : elle peut être déclenchée avant que le code de votre site ou de votre CMS ne s'exécute. Autrement dit, ni le thème, ni l'extension, ni le pare-feu applicatif ne vous en protègent par construction.

Et c'est là que se joue la différence entre « panne » et « mise à l'arrêt ». Quand un correctif vient de sortir et que des preuves de concept circulent déjà, un administrateur qui ne peut pas redéployer dans l'heure n'a qu'une mesure réellement sûre : débrancher. C'est exactement ce qu'ont fait l'Anssi et plusieurs gouvernements européens. Ce que vous avez vu ce soir n'est donc pas une panne d'Internet : c'est un retrait volontaire, le temps de colmater.

🔬 Les deux failles, sans jargon inutile

CVE-2026-109618 — une corruption de mémoire pendant la gestion d'un dépassement de mémoire. PHP interrompt une requête trop gourmande avec un mécanisme brutal ; si l'interruption tombe au mauvais moment (pendant l'analyse d'un envoi de fichier, par exemple), le nettoyage qui suit peut libérer de la mémoire jamais initialisée — mémoire qui contient encore des données choisies par l'attaquant.

CVE-2026-109619 — un état global périmé. Un processus qui traite les requêtes les unes après les autres peut conserver des restes d'une requête précédente, notamment après une erreur fatale, et les réutiliser pour la suivante.

Toutes les façons de servir PHP sont concernées : PHP-FPM, mod_php (jugé le plus risqué par l'équipe PHP), php-cgi, FrankenPHP, LiteSpeed. Une seule requête non authentifiée suffit. Sont affectées les versions 8.5 < 8.5.12, 8.4 < 8.4.27, 8.3 < 8.3.36 et 8.2 < 8.2.35. Les branches en fin de vie (8.1 et antérieures) ne recevront pas de version corrigée : il faut passer par le paquet de votre distribution ou migrer.

« Compte tenu de leur gravité et de la large diffusion de PHP, nous considérons ceci comme l'un des problèmes de sécurité avec le plus gros impact de mémoire récente. »
— Wiz (filiale de Google), cité par actu.fr, 21 octobre 2026

✅ Ce que nous avons vérifié ce soir, sur nos sites

Nous avons sondé nos domaines à 21h34, pendant que l'incident était en cours. Tous répondaient en HTTP 200, entre 41 et 144 millisecondes :

• alpesdata.com — HTTP 200
• massagepro.fr (site client, marque Robot Masseur) — HTTP 200
• ma-therapie.fr — HTTP 200
• foundation.immo — HTTP 200
• alice.moranval.com — HTTP 200

Ce n'est pas de la chance, et ce n'est pas non plus une promesse en l'air : c'est une conséquence de l'architecture. Aucun des sites que nous concevons n'exécute PHP. Ce sont des pages statiques — HTML, CSS, JavaScript — servies par nginx, sans base de données exposée et sans CMS à mettre à jour. Le seul élément dynamique de nos sites est le formulaire de contact, qui passe par un service Python (FastAPI) séparé, et n'a rien à voir avec PHP.

Une faille d'exécution de code dans PHP n'a donc rien à exécuter sur nos serveurs : il n'y a pas d'interpréteur PHP pour recevoir la requête malformée. C'est l'un des avantages concrets du statique, celui dont on parle rarement et qui compte les soirs comme celui-ci : moins de pièces mobiles, moins de surface d'attaque, et rien à recoller dans l'urgence.

Côté outils internes, nous ne prétendons pas vivre sans PHP : les deux services PHP que nous exploitons pour l'administration et le stockage de fichiers tournaient déjà, à 21h40, sur les versions corrigées (8.4.27 et 8.5.12). Ce sont des outils d'usage interne, pas des sites publiés — mais ils sont suivis comme le reste.

Deux précisions, pour rester exacts. Cela couvre les sites que nous avons conçus et hébergeons ; cela ne couvre pas les outils tiers que vous utilisez par ailleurs (une boutique, un espace client, un WordPress installé chez un autre prestataire), ni les incidents qui viendraient d'ailleurs — DNS, hébergeur, opérateur. Aucune architecture ne rend invulnérable, et nous ne prétendrons pas le contraire.

🛠️ Vous avez un site en PHP ? Les gestes à faire maintenant

1. Connaître sa version. Demandez-la à votre hébergeur, ou php -v en ligne de commande. Si vous ne savez pas, considérez que le site est exposé.
2. Mettre à jour vers 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 — les quatre versions corrigées publiées le 21 octobre. Sur un serveur géré par votre hébergeur, ce peut être fait pour vous : vérifiez, ne supposez pas.
3. Si vous êtes en 8.1 ou antérieur (fin de vie) : il n'y a pas de version corrigée. Passez par le paquet de votre distribution, ou migrez vers 8.2 au minimum. C'est le cas le plus urgent.
4. Si vous ne pouvez pas corriger tout de suite : coupez le service. C'est la recommandation de l'Anssi, de la NSA et du NCSC britannique. Un site inaccessible une soirée coûte moins cher qu'un serveur pris. Un pare-feu applicatif (WAF) peut filtrer une partie des tentatives, il ne corrige pas la faille.
5. Après la mise à jour, regardez les traces. Des erreurs de dépassement de mémoire inhabituelles, des envois de fichiers anormaux, des processus ou des fichiers apparus dans /tmp : en cas de doute, restaurez depuis une sauvegarde saine et changez les secrets (mots de passe, clés, jetons).

Sur WordPress en particulier, la version de PHP est celle de l'hébergeur, pas celle du CMS : mettre à jour WordPress ne suffit pas. Et si vous utilisez un plugin de sécurité, aucun ne dispense de la mise à jour du langage lui-même.

🏔️ La position d'Alpesdata

Nous concevons des sites statiques d'abord : c'est un choix de sobriété, de vitesse et de sécurité. Pas de CMS à surveiller, pas de base de données à durcir, pas de chaîne d'extensions à suivre — et, ce soir, rien à éteindre. Quand un client a besoin d'un outil dynamique, nous l'isolons, nous le documentons et nous expliquons ce qu'il implique en matière de maintenance : c'est un arbitrage à connaître, pas un détail technique.

Ce qui s'est passé aujourd'hui ne relève pas de l'accident exotique. Deux failles critiques en un jour, des preuves de concept qui circulent en quelques heures, des gouvernements qui coupent leurs propres sites : c'est le rythme auquel il faut désormais savoir réagir. La bonne réponse n'est pas de courir après chaque alerte, mais d'avoir moins de choses à corriger et de savoir, en une minute, ce qui tourne sur ses serveurs. C'est exactement ce que nous vendons à nos clients — et ce que nous venons de vérifier chez nous.