Cybersecurite 02 Nov 2026 · 1 min de lecture

Failles PHP critiques : l'exploitation a commencé, que faire ?

Equipe Redaction

Expert INNOSYS

PHP fait tourner une grande partie du web : sites vitrines, extranets, CMS, portails clients, outils métiers développés il y a dix ans et jamais vraiment revus. Deux vulnérabilités critiques, corrigées le 21 octobre, permettent d'en prendre le contrôle à distance sans authentification. Depuis le 26 octobre, le CERT-FR indique observer des tentatives d'exploitation. Le temps de l'observation est terminé.

Ce qui s'est passé en dix jours

La chronologie mérite d'être posée, car elle illustre la vitesse à laquelle une vulnérabilité passe du bulletin à l'attaque.

Le 20 octobre 2026, le projet PHP pré-annonce une publication de sécurité pour le lendemain, 14 h UTC, en précisant que les deux failles concernées sont notées 9,2 selon le barème CVSS v4.0. Le 21 octobre, les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35 sont publiées. L'avis de sécurité est sans ambiguïté : ces versions « corrigent deux vulnérabilités critiques pouvant permettre une exécution de code à distance non authentifiée ».

Les deux failles portent les identifiants CVE-2026-109618 (exécution de code via une corruption liée au dépassement mémoire) et CVE-2026-109619 (exécution de code via un état global résiduel). Le même jour, le CERT-FR publie l'alerte CERTFR-2026-ALE-014 sur ces « multiples vulnérabilités dans PHP ».

Toujours le 21 octobre, les sites de plusieurs préfectures, dont celui de la préfecture de police de Paris, ont été placés en « maintenance préventive » à la demande de l'ANSSI, selon le ministère de l'Intérieur cité par 20 Minutes et l'AFP. Le ministère évoquait une vulnérabilité critique « annoncée il y a quelques heures par l'éditeur d'un composant logiciel générique », sans nommer ce composant. Le site spécialisé donneespersonnelles.fr rattache ces déconnexions à la vulnérabilité surnommée « PHP2Shell ».

Ensuite, tout s'accélère. Le 22 octobre, le CERT-FR met à jour son alerte : des preuves de concept sont publiquement connues. Le 23 octobre, PHP publie un avis sur une troisième faille, CVE-2026-115560, dont le correctif est renvoyé au prochain cycle de publication ; le CERT-FR l'intègre à son alerte le 26 octobre. Le même jour, selon Armées.com, le CERT-FR indique avoir observé des tentatives d'exploitation visant des « déploiements spécifiques ». Le 27 octobre, l'alerte est à nouveau précisée sur les produits affectés et les mesures de remédiation.

Point important : le CERT-FR ne communique pas de nombre de victimes, et une tentative d'exploitation n'est pas une compromission avérée. Mais en sécurité, la fenêtre entre « preuve de concept publique » et « exploitation de masse » se compte rarement en semaines.

Qui est concerné ?

Les versions maintenues non mises à jour

Selon l'alerte du CERT-FR, sont affectées les versions 8.2.x antérieures à 8.2.35, 8.3.x antérieures à 8.3.36, 8.4.x antérieures à 8.4.27 et 8.5.x antérieures à 8.5.12. Autrement dit, tout serveur qui n'a pas reçu de mise à jour PHP depuis le 21 octobre est potentiellement exposé.

Les versions obsolètes : le vrai angle mort

L'alerte liste également toutes les versions 5.x, 7.x, 8.0.x et 8.1.x. Ces branches ne reçoivent plus de correctifs du projet PHP. L'avis officiel renvoie vers des branches de rétroportage minimal pour 7.4, 8.0 et 8.1, mais la recommandation de fond reste la migration.

C'est ici que se concentre, sur le terrain, l'essentiel du risque. Dans les PME et ETI que nous accompagnons, nous croisons régulièrement des applications PHP 7 — parfois PHP 5 — qui tournent « parce qu'elles marchent » : un extranet partenaires, un module de prise de rendez-vous, un back-office développé par un prestataire disparu depuis. Ces serveurs n'ont souvent pas de propriétaire clairement identifié. Ce sont précisément ceux qu'un attaquant trouvera avant vous.

À noter également : la branche PHP 8.2 arrive en fin de vie le 31 décembre 2026, selon le calendrier du projet. Une application en 8.2 corrigée aujourd'hui sera de nouveau sans filet dans deux mois.

Les configurations les plus exposées

D'après Armées.com, le mode d'exécution mod_php (PHP intégré directement au serveur Apache) présenterait le risque le plus élevé. Les environnements Windows ne sont pas épargnés par l'actualité : le 26 octobre, PHP a publié des builds Windows mis à jour (8.5.12-1, 8.4.27-1, 8.3.36-1, 8.2.35-1) intégrant Brotli 1.2.1, qui corrige une autre vulnérabilité (CVE-2026-111497).

Ce que dit le CERT-FR sur les contournements

L'alerte est claire : « Seule l'application de la mise à jour permet de vous prémunir. » Le CERT-FR liste néanmoins des mesures d'atténuation temporaires pour les cas où la mise à jour ne peut être immédiate, parmi lesquelles :

le paramétrage de memory_limit et d'une valeur basse pour post_max_size ;
la désactivation du suivi de progression des uploads de session (session.upload_progress.enabled=0), suivie d'un redémarrage des processus ;
pour PHP 8.5, la désactivation de fatal_error_backtraces.

Ces réglages peuvent casser des fonctionnalités (envoi de fichiers volumineux, barres de progression) et ne remplacent pas le correctif. Ils servent à gagner quelques jours, pas à clore le sujet. Armées.com souligne d'ailleurs que certaines atténuations circulant en ligne ne sont pas qualifiées par le CERT-FR.

Notre lecture : un test grandeur nature de votre gestion des vulnérabilités

Cette alerte n'a rien d'exceptionnel dans sa nature : une faille critique dans un composant ultra-répandu, un correctif disponible, une exploitation qui démarre. C'est justement pour cela qu'elle est révélatrice. Elle pose trois questions très simples à toute direction :

Savez-vous, en moins d'une heure, combien de serveurs exécutent PHP chez vous — et chez vos hébergeurs ou prestataires ? Sans inventaire à jour, la réponse prend des jours.
Qui a l'autorité pour patcher en urgence une application de production ? Dans beaucoup d'organisations, la mise à jour attend la fenêtre de maintenance mensuelle, ou la validation d'un éditeur.
Que faites-vous des applications qui ne peuvent pas être mises à jour ? Une application bloquée en PHP 7 parce que son code n'est pas compatible avec PHP 8 est une dette technique qui devient, ce mois-ci, une dette de sécurité.

Pour les organisations qui entreront dans le périmètre de NIS2, ce type d'épisode correspond exactement à ce que la directive attend : une gestion des vulnérabilités documentée et réactive, et une maîtrise de la chaîne d'approvisionnement — y compris des prestataires qui hébergent ou maintiennent vos applications web. La transposition française se fait attendre, mais les attaquants, eux, n'attendent pas de texte de loi.

Enfin, la séquence des préfectures rappelle une réalité opérationnelle : mettre un service hors ligne de manière préventive est parfois la décision la plus responsable. Encore faut-il l'avoir anticipée — qui décide, qui prévient les utilisateurs, combien de temps l'activité peut s'en passer.

Ce qu'il faut faire maintenant

Inventorier dès aujourd'hui toutes les instances PHP, internes comme externalisées : serveurs web, conteneurs, CMS, outils métiers, environnements de recette exposés. Demandez par écrit à vos hébergeurs et prestataires leur statut de correction sur CERTFR-2026-ALE-014.
Appliquer les versions 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 sur tout ce qui est exposé sur Internet en priorité, puis sur le réseau interne. Sur Windows, privilégiez les builds « -1 » publiés le 26 octobre.
Isoler ou couper les applications en PHP 5.x, 7.x, 8.0 et 8.1 qui ne peuvent pas être corrigées immédiatement : restriction d'accès (VPN, filtrage IP), pare-feu applicatif, atténuations du CERT-FR — en attendant une migration planifiée.
Rechercher des traces de compromission sur les serveurs exposés depuis le 21 octobre : fichiers PHP récemment créés dans les répertoires web, processus inhabituels, connexions sortantes inattendues. Un correctif appliqué sur un serveur déjà compromis ne suffit pas.
Inscrire au budget 2027 la sortie de PHP 8.2 et des versions antérieures, avec un propriétaire nommé pour chaque application web. C'est le moment de trancher entre migration, refonte ou décommissionnement.

En conclusion

Les correctifs existent depuis le 21 octobre ; le risque, désormais, ne tient plus à la faille elle-même mais au délai de réaction de chaque organisation. Les entreprises qui disposent d'un inventaire fiable et d'un circuit de décision court auront traité le sujet en quelques jours. Pour les autres, c'est l'occasion de construire ce socle.

Chez Innosys, nous accompagnons au quotidien des PME et ETI sur ces deux volets : l'administration et le durcissement des serveurs, et la modernisation des applications PHP vieillissantes. Si cette alerte met en lumière des zones grises dans votre parc, nous pouvons en parler.