Deux failles au score de criticité maximal
Le 21 octobre 2026, l'ANSSI publie via le CERT-FR une alerte concernant deux vulnérabilités dans PHP, référencées CVE-2026-109618 et CVE-2026-109619. Leur score CVSS atteint 9,2 sur 10, ce qui les classe dans la catégorie « critique » : un attaquant peut exécuter du code arbitraire à distance, sans aucune authentification préalable. L'impact potentiel couvre la prise de contrôle d'un serveur, l'exfiltration de données et l'installation d'un rançongiciel.
Le périmètre touché est étendu. Les vulnérabilités affectent les branches PHP de la version 5 à 8.1, ainsi que certaines versions antérieures aux correctifs des branches 8.2 à 8.5. Les versions corrigées sont disponibles : PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12. En théorie, la correction est directe. En pratique, elle oblige à identifier l'ensemble des environnements concernés, ce qui suppose un inventaire applicatif que beaucoup d'organisations n'ont pas tenu à jour.
La réaction du secteur public illustre la difficulté de l'arbitrage. Plusieurs préfectures ont suspendu temporairement l'accès à leurs services en ligne pour réduire le risque d'exploitation. Ce choix entre continuité de service et sécurité immédiate, de nombreuses entreprises privées devront aussi le trancher dans les prochains jours.
PHP, le socle invisible de milliers d'applications d'entreprise
La majorité des directions générales n'ont jamais eu à se préoccuper de PHP. C'est précisément là que réside le problème. PHP reste l'un des langages les plus utilisés pour le développement web, présent dans des back-offices, des intranets, des portails clients et des modules de paiement développés ou déployés il y a dix, quinze, parfois vingt ans. Ces systèmes tournent souvent sur des versions anciennes, sans support officiel actif, et sans que personne n'ait de vue précise sur leur état.
Le cas le plus exposé n'est pas celui de l'entreprise qui utilise PHP en connaissance de cause, avec une politique documentée de mises à jour. C'est celui de l'organisation qui ne sait pas qu'elle fait tourner du PHP : parce que ce code est enfoui dans une application métier confiée à un prestataire externe il y a plusieurs années, ou dans un plugin de CMS dont les mises à jour ne sont plus suivies. Dans ces situations, une alerte critique peut rester sans réponse pendant des semaines, faute de visibilité sur le patrimoine logiciel.
Selon l'analyse publiée par Le Monde Informatique au lendemain de l'alerte, deux mesures temporaires permettent de réduire une partie du risque en attendant la mise à jour : désactiver l'option session.upload_progress.enabled et bloquer les requêtes dont le Content-Type est multipart. Ces paramètres techniques ne remplacent pas les correctifs, mais ils offrent une fenêtre pour organiser la migration sans laisser les systèmes entièrement exposés.
Une alerte dans un paysage cyber qui se tend
Ces failles PHP ne surviennent pas dans un contexte stable. Selon les données internes de l'assureur Markel relayées par Maddyness, le nombre de rançongiciels recensés dans le monde a augmenté de 76 % au troisième trimestre 2026 par rapport au même trimestre de 2025. Cette hausse concerne en particulier le secteur financier et les fintech, dont les interfaces web constituent autant de surfaces d'attaque potentielles.
Dans ce contexte, une vulnérabilité permettant l'exécution de code à distance sans authentification représente exactement le type de porte d'entrée que les groupes cybercriminels cherchent à exploiter. La découverte de ces deux failles avec l'aide d'outils d'IA illustre par ailleurs une tendance structurelle : l'intelligence artificielle accélère la détection des vulnérabilités, mais la capacité des organisations à corriger leurs systèmes reste contrainte par des facteurs humains et organisationnels. La vitesse de découverte augmente; la vitesse de correction, elle, ne suit pas automatiquement.
Pour les directions financières, le lien avec les rançongiciels n'est pas théorique. Une attaque réussie via une faille PHP non corrigée peut paralyser des systèmes de paiement, compromettre des données clients, déclencher des obligations de notification réglementaire et générer des coûts de remédiation qui se chiffrent rapidement en dizaines, voire en centaines de milliers d'euros, selon la taille de l'organisation et la durée de l'interruption.
Ce que les directions doivent faire : un inventaire d'abord
La réponse habituelle face à ce type d'alerte consiste à transmettre un email à la DSI ou au prestataire, puis à attendre. C'est insuffisant. Les vulnérabilités PHP peuvent affecter la continuité des services en ligne, la sécurité des données clients et les outils de gestion interne, autant de domaines qui engagent la responsabilité légale et financière de l'entreprise, pas seulement son département IT.
La première décision à prendre est un inventaire : quelles applications, quels sites, quels outils internes reposent sur PHP ? Quelle version est en production ? Qui est responsable des mises à jour, et selon quel calendrier contractuel ? Ces questions paraissent élémentaires, mais dans beaucoup de PME et d'ETI, elles n'ont pas de réponse immédiate. L'absence de visibilité sur le patrimoine applicatif est en soi un indicateur de risque opérationnel.
La deuxième décision concerne les hébergeurs et prestataires. Tout hébergeur géré doit être en mesure d'indiquer dans quel délai il applique les correctifs critiques et selon quelles conditions contractuelles. Un contrat qui ne prévoit pas ce niveau d'engagement présente une lacune à corriger lors des prochaines renégociations.
Du côté des assurances, la hausse documentée des rançongiciels ne restera pas sans conséquences sur les primes et les conditions d'accès aux polices cyber. Les assureurs imposent déjà des audits préalables et des exigences de conformité croissantes. Une organisation incapable de démontrer qu'elle maintient ses composants logiciels à jour risque de voir sa couverture limitée, voire conditionnée à des investissements de mise en conformité urgents.
L'alerte ANSSI sur PHP illustre une réalité qui s'impose progressivement aux comités de direction : la cybersécurité n'est plus un poste délégué à l'IT, mais une composante du risque opérationnel et financier, à gérer avec la même rigueur que la liquidité ou la conformité réglementaire. Dans un environnement où l'IA abaisse le coût d'entrée pour les attaquants, la qualité de l'inventaire logiciel et la rapidité de correction des vulnérabilités deviennent des indicateurs de santé d'entreprise à part entière.
