Faille de sécurité applicative : que faire quand elle tombe, et comment s’y préparer

Une faille de sécurité applicative ne prévient pas, et elle tombe rarement au bon moment. Le 21 octobre 2026, deux vulnérabilités critiques de PHP ont obligé des équipes techniques à agir en quelques heures : inventorier ce qui tournait, puis appliquer les mises à jour de sécurité publiées sur quatre branches du langage, sans toujours savoir ce qui était réellement exposé.

PHP n’est ici qu’un exemple. La prochaine fois, ce sera un framework, une bibliothèque ou un composant serveur. Ce qui change peu, c’est la façon de réagir. Nous détaillons les réflexes à avoir face à une faille critique, ce qu’on fait quand aucun correctif n’existe, et pourquoi la préparation compte autant que la rapidité.

Ce qui s’est passé avec PHP, et pourquoi cela dépasse PHP

Les deux failles, référencées CVE-2026-109618 et CVE-2026-109619, permettent à un attaquant de provoquer une exécution de code arbitraire à distance, selon l’alerte du CERT-FR. D’après le CERT Santé, l’attaque se produit avant l’exécution du code de l’application. Elle a été démontrée sur Apache avec le module mod_php dans sa configuration par défaut, et PHP-FPM, php-cgi, FrankenPHP et LiteSpeed sont aussi concernés. Cybermalveillance.gouv.fr juge ces failles particulièrement critiques pour les sites transactionnels, ceux qui manipulent des données sensibles et ceux qui ont des connexions vers des systèmes internes.

Autrement dit, la qualité du développement de votre application n’y change rien : le problème se situe en dessous, hors de votre code. Le CERT-FR recommande d’isoler les équipements affectés, puis de migrer vers une version maintenue disposant des derniers correctifs. Face à une exécution de code à distance, attendre peut coûter plus cher qu’une indisponibilité maîtrisée.

Faille de sécurité applicative : que faire, dans l’ordre

Les consignes du CERT-FR, de Cybermalveillance.gouv.fr et du CERT Santé sur cette alerte donnent une base solide, valable bien au-delà de PHP. Nous y avons ajouté un dernier point, la communication, que les consignes officielles ne traitent pas.

Le troisième point est celui qui bloque le plus souvent. Sans tests ni environnement de recette, on hésite à appliquer une mise à jour de sécurité en production, et pendant l’hésitation l’exposition continue. C’est pourquoi isoler temporairement l’application d’Internet reste une option : le CERT Santé la mentionne quand la mise à jour est impossible. Il rappelle aussi un détail facile à oublier : redémarrer tous les workers PHP après la mise à jour.

Quand il n’existe pas de correctif

Un correctif ne couvre que les versions encore maintenues. Pour PHP, les versions 5.x, 7.x, 8.0.x et 8.1.x ne reçoivent plus de correctifs de sécurité de l’éditeur, et figurent pourtant parmi les systèmes affectés, d’après l’alerte du CERT-FR. Certaines distributions Linux et certains fournisseurs de support à long terme proposent des correctifs rétroportés, précise le CERT Santé. Pour une application qui tourne sur une version plus ancienne, la réponse n’est donc pas un correctif : c’est un projet de migration, avec son délai, mené sous pression.

C’est le scénario le plus coûteux, et il se prépare bien avant l’alerte : une application dont personne n’a touché les dépendances depuis des années accumule un retard qu’une faille critique transforme en urgence. Les signaux d’une application legacy se repèrent à froid. Un audit de sécurité applicative donne la photographie des versions et des dépendances à traiter, comme le montre notre retour sur l’audit d’une application PHP en production.

Notre livre blanc sur l’audit applicatif va plus loin : il revient sur les technologies qui ne reçoivent plus de correctifs officiels (PHP, Symfony, Laravel), sur ce que cela implique pour l’entreprise, et sur la façon de choisir entre stabiliser, moderniser par lots ou refondre.

Une faille n’est jamais vraiment réglée en une seule fois

Les alertes évoluent d’un jour à l’autre. Le CERT-FR a eu connaissance de preuves de concept dès le 22 octobre, pour des déploiements spécifiques de PHP. Le CERT Santé indique de son côté avoir observé des tentatives d’exploitation depuis le 17 octobre, donc avant la publication des correctifs, puis en forte hausse après le 21. Le 23 octobre, PHP a signalé une troisième vulnérabilité, CVE-2026-115560. Elle ne concerne qu’une configuration inhabituelle, aucune exploitation n’est connue et son correctif est prévu dans la prochaine version régulière. La mesure d’atténuation session.upload_progress.enabled=0 la couvre aussi, selon le CERT Santé.

Ce rythme n’a rien d’exceptionnel. PHP avait déjà publié des correctifs de sécurité le 30 juillet 2026, moins de trois mois avant ceux d’octobre. Une mise à jour de sécurité n’est pas un événement isolé : c’est un flux, et quelqu’un doit le suivre. Chaque avis oblige à vérifier si l’application est concernée, à tester, puis à déployer. Multipliez par le nombre d’applications que vous exploitez, et par les mois d’une année.

Semaine subie ou semaine maîtrisée

Chez Mink, nous sommes intervenus la semaine dernière chez plusieurs clients. Dans ce genre de situation, il faut agir vite, et tout dépend de ce qui existe déjà quand l’alerte arrive.

Sans contrat, on s’en sort aussi. Mais une partie du temps part dans l’organisation plutôt que dans la correction, et ce temps compte quand la faille est publique.

Ce qu’un contrat de maintenance applicative doit prévoir face à une faille critique

Un contrat de maintenance se juge sur ce qu’il prévoit le jour où une alerte tombe. Six points méritent d’être vérifiés :

• Le périmètre : quelles applications, quels environnements (production, recette), quelles dépendances.
• Les délais de prise en charge selon la criticité. Une faille critique n’appelle pas le même délai qu’une anomalie d’affichage. Notre article sur la TMA détaille comment les définir.
• Les mises à jour de sécurité : sont-elles incluses, et sous quel délai après la publication d’un avis ?
• Les tests et la recette après chaque intervention.
• Le reporting : ce qui a été traité, ce qui reste ouvert.
• La réversibilité : accès au code, aux données et à la documentation, pour ne pas dépendre d’un seul prestataire. Voir la clause de réversibilité.

Les niveaux de service dépendent de l’application : chez Mink, nous les définissons avec chaque client, parce qu’une application métier critique n’appelle pas la même urgence qu’un site institutionnel. Pour un développement sur-mesure réalisé chez nous, la même équipe en assure ensuite la maintenance. Notre offre de maintenance et d’hébergement et notre méthodologie précisent comment nous travaillons.

Si vous n’avez pas de contrat aujourd’hui, la première étape n’est pas d’en signer un. C’est de savoir ce que vous avez à protéger. Le diagnostic de criticité de votre applicatif métier permet de classer vos applications selon le risque qu’elles représentent.

En résumé

Face à une faille critique, on agit dans l’ordre : inventorier, prioriser, corriger ou isoler, vérifier, suivre, communiquer. Quand la version utilisée n’est plus maintenue, il n’y a pas de correctif, seulement une migration. Et un correctif ne clôt rien : les avis se succèdent, comme l’a montré la troisième vulnérabilité signalée le 23 octobre sur PHP. Un contrat de maintenance applicative ne supprime pas les failles. Il garantit que l’inventaire, les priorités, les tests et les interlocuteurs existent déjà quand l’une d’elles est publiée.