Le CERT-FR, le centre gouvernemental de veille et de réponse aux attaques informatiques rattaché à l’ANSSI, a publié le 21 octobre 2026 une alerte de niveau maximal concernant PHP. Référencée CERTFR-2026-ALE-014, elle signale deux vulnérabilités critiques qui permettent à un attaquant de provoquer une exécution de code arbitraire à distance sur les serveurs concernés. Autrement dit : un serveur vulnérable et exposé peut être pris en main sans que son administrateur ne s’en aperçoive. Pour un langage qui motorise une écrasante majorité des sites web, des intranets et des outils de gestion documentaire, l’affaire mérite qu’on s’y arrête.
Les points :
Deux failles critiques, des correctifs publiés le 21 octobre #
Selon l’alerte du CERT-FR, l’équipe de PHP a communiqué le 20 octobre 2026 sur l’existence de ces deux vulnérabilités, enregistrées sous les références CVE-2026-109618 et CVE-2026-109619. Les correctifs ont été mis à disposition le lendemain, le 21 octobre 2026 à 16 h (heure de Paris), sur le site officiel du langage.
Le scénario est classique mais redoutable : entre la communication de l’éditeur et l’application effective des correctifs par les administrateurs, il s’écoule toujours un délai pendant lequel les attaquants travaillent à reconstituer la faille à partir des indices publiés. C’est précisément cette fenêtre que le CERT-FR cherche à réduire en publiant une alerte, un format réservé aux menaces jugées les plus sérieuses, et non un simple avis de sécurité.
À lire Nmap : Guide Scan Réseau Complet 2026
Êtes-vous concerné ? La liste des versions touchées #
L’alerte dresse une liste large. Sont vulnérables, d’après le CERT-FR :
Les branches encore maintenues
Les versions 8.2.x antérieures à 8.2.35, les versions 8.3.x antérieures à 8.3.36, les versions 8.4.x antérieures à 8.4.27 et les versions 8.5.x antérieures à 8.5.12. Pour toutes celles-ci, la marche à suivre est simple : installer la version corrigée publiée le 21 octobre.
Les branches en fin de vie
C’est le point le plus préoccupant : toutes les versions 5.x, 6.x, 7.x, 8.0.x et 8.1.x sont également vulnérables, et celles-ci ne sont plus supportées par l’éditeur. Elles ne recevront donc aucun correctif. Or ces branches anciennes restent massivement présentes sur les hébergements mutualisés, les serveurs d’entreprise vieillissants et les applications métier qui n’ont jamais été migrées. Le calendrier officiel de support de PHP le rappelle : seules les branches 8.2 à 8.5 bénéficient encore de correctifs de sécurité.
Les recommandations du CERT-FR #
Face à ces deux failles, l’organisme formule deux consignes principales : isoler les équipements affectés tant qu’ils ne sont pas corrigés, et migrer vers une version maintenue de PHP en appliquant les correctifs dès leur publication. Pour les serveurs qui tournent encore sur une branche en fin de vie, il n’existe pas de demi-mesure : la migration vers PHP 8.2 ou plus récent est la seule voie pour retrouver un socle corrigé.
À lire Les 10 meilleurs scanners IP gratuits pour votre réseau
En attendant de pouvoir mettre à jour, l’alerte décrit deux mesures de contournement provisoires, que le CERT-FR précise ne pas avoir qualifiées lui-même. La première consiste à désactiver la fonctionnalité de suivi de progression des téléversements, en passant la directive session.upload_progress.enabled à Off dans le fichier php.ini (ou via php_admin_flag pour les installations PHP-FPM). Attention toutefois : cette mesure ne réduit la surface d’attaque que pour l’une des deux vulnérabilités. La seconde consiste à bloquer, par exemple au niveau d’un pare-feu applicatif (WAF), les requêtes HTTP dont l’en-tête Content-Type est de type multipart — et si ce blocage est impossible sans casser des fonctionnalités légitimes, à superviser étroitement ce type de requêtes.
Ce que cela implique concrètement pour une PME #
Beaucoup d’organisations ne savent tout simplement pas quelles versions de PHP tournent dans leur parc. Un site vitrine installé il y a huit ans, une GED interne, un vieux portail de numérisation de documents ou un serveur d’impression avec interface web embarquée peuvent très bien reposer sur une branche 7.x oubliée. La première étape est donc un inventaire : recenser les machines exposées, interroger la version de PHP servie (elle apparaît souvent dans les en-têtes HTTP ou via les outils d’administration de l’hébergeur) et croiser le résultat avec la liste des versions vulnérables.
C’est exactement le type de situation où un scan régulier de son propre réseau prend tout son sens : détecter les services exposés, identifier les versions obsolètes et prioriser les mises à jour avant qu’un attaquant ne fasse le même travail à votre place. Les hébergements mutualisés ne sont pas à négliger non plus : si votre site est chez un hébergeur, vérifiez dans votre panneau d’administration que la version de PHP sélectionnée est bien l’une des versions corrigées, et changez-la vous-même si nécessaire — c’est généralement un simple menu déroulant.
Une piqûre de rappel sur l’hygiène de version #
Cette alerte illustre une règle que les équipes de sécurité répètent inlassablement : le coût d’une migration planifiée est toujours inférieur au coût d’une compromission. Les branches anciennes de PHP continueront d’accumuler des vulnérabilités sans correctif, et chaque nouvelle alerte élargira l’écart de risque entre les parcs à jour et les autres. Mettre en place une veille sur les alertes du CERT-FR, tenir un inventaire des versions déployées et se réserver des créneaux de mise à jour réguliers : trois habitudes simples qui, cette semaine encore, font la différence entre une mise à jour de routine et une astreinte de crise.
