Failles critiques PHP d’octobre 2026 : votre site est-il vraiment protégé ?
Votre site fonctionne, les commandes arrivent et personne ne signale de problème. Pourtant, une version PHP vulnérable peut exposer votre application à une compromission. Les alertes d’octobre 2026 rappellent pourquoi une simple mise à jour ne suffit pas toujours.
Votre site fonctionne parfaitement.
Les clients peuvent se connecter. Les commandes arrivent. Les formulaires répondent normalement.
Votre prestataire informatique vous explique que tout est à jour.
Mais une question mérite d’être posée :
Quelle version de PHP exécute réellement votre site, et dispose-t-elle des derniers correctifs de sécurité ?
Depuis le 21 octobre 2026, cette question est devenue particulièrement importante.
Le CERT-FR, rattaché à l'ANSSI, a publié une alerte concernant deux vulnérabilités critiques de PHP : CVE-2026-109618 et CVE-2026-109619.
Le risque identifié est sérieux : l'exécution de code arbitraire à distance, dans les conditions d'exploitation concernées.
Le 22 octobre, le CERT-FR a également confirmé avoir connaissance de preuves de concept pour certains déploiements.
Cela ne signifie pas que tous les sites PHP ont été piratés. Mais cela justifie une vérification rapide, surtout lorsque l'application est accessible depuis Internet.
Pourquoi un site qui fonctionne peut quand même être vulnérable
C'est l'un des malentendus les plus fréquents en informatique.
On suppose qu'un système en bon état est un système sécurisé.
Pourtant, une vulnérabilité peut rester invisible pendant des mois.
Un site peut servir ses pages normalement tout en utilisant un composant qui présente un risque de sécurité.
PHP est utilisé par de nombreuses applications web, notamment WordPress, des boutiques en ligne et des applications développées sur mesure.
Et PHP ne tourne pas toujours là où l'on croit.
Il peut être installé directement sur un serveur, exécuté avec PHP-FPM, intégré à Apache ou fourni par une image Docker.
Mettre à jour le système d'exploitation ne garantit donc pas automatiquement que toutes les instances PHP utilisées par l'entreprise ont été corrigées.
Quelles versions de PHP sont concernées ?
Selon l'alerte CERTFR-2026-ALE-014, publiée le 21 octobre et mise à jour le 22 octobre 2026, les versions concernées comprennent :
Les versions hors support ne disposent plus des corrections de sécurité de l'éditeur PHP.
Attention toutefois : certaines distributions Linux proposent leurs propres paquets intégrant des correctifs rétroportés. La vérification doit donc tenir compte de la provenance et de la version exacte du paquet, pas uniquement du numéro affiché par php -v.
Source : CERT-FR — CERTFR-2026-ALE-014
Les cinq vérifications à effectuer
1. Identifier le PHP réellement utilisé en production
Sur un serveur, la commande php -v donne une première indication.
Mais elle affiche la version du PHP exécuté en ligne de commande.
Ce n'est pas nécessairement celle utilisée par votre serveur web.
Il faut également examiner les services PHP-FPM, la configuration Apache ou Nginx et, le cas échéant, les conteneurs Docker.
2. Vérifier les applications oubliées
Le site principal n'est pas toujours le plus grand risque.
Une ancienne interface d'administration, un extranet client, un environnement de recette ou un sous-domaine encore accessible peuvent utiliser une version différente de PHP.
L'objectif est de connaître toutes les instances exposées, pas uniquement celle du site vitrine.
3. Identifier les correctifs réellement installés
Une version semble ancienne ?
Il faut vérifier les avis de sécurité de la distribution, les paquets installés et les correctifs disponibles.
Dans un environnement Docker, corriger PHP dans un conteneur temporaire ne suffit pas.
Il faut reconstruire l'image, déployer la nouvelle version et vérifier le conteneur réellement exécuté.
4. Examiner les traces d'activité suspecte
Une mise à jour corrige une vulnérabilité.
Elle ne permet pas de prouver qu'aucun attaquant n'a déjà exploité le système.
En cas de suspicion, les journaux HTTP, les événements applicatifs, les modifications inhabituelles de fichiers et les connexions sortantes méritent une investigation.
La présence d'une version vulnérable ne prouve pas une compromission. Il faut distinguer les deux situations.
5. Préparer une correction sans casser la production
Sur un site e-commerce ou une application métier, une mise à jour réalisée sans préparation peut provoquer une indisponibilité.
Avant le déploiement, il faut prévoir une sauvegarde, tester les dépendances, vérifier les fonctionnalités critiques et disposer d'une procédure de retour arrière.
L'objectif n'est pas seulement de mettre à jour.
C'est de réduire le risque sans créer un nouvel incident de production.
Un WAF peut-il remplacer la mise à jour ?
Non.
Le CERT-FR décrit certaines mesures d'atténuation provisoires, notamment des restrictions portant sur les requêtes HTTP multipart et la désactivation d'une fonctionnalité PHP spécifique.
Mais ces contournements ne sont pas qualifiés par le CERT-FR comme des protections suffisantes pour toutes les situations.
Ils ne remplacent donc pas les correctifs de sécurité.
Un pare-feu applicatif peut réduire certaines possibilités d'exploitation. Il ne garantit pas qu'une application vulnérable soit protégée.
La question à poser à votre prestataire
Plutôt que de demander :
« Notre serveur est-il à jour ? »
Demandez :
« Pouvez-vous me confirmer toutes les versions de PHP réellement utilisées en production, les correctifs installés et les applications qui restent exposées ? »
La différence est importante.
La première question appelle une réponse rassurante.
La seconde demande des éléments vérifiables.
Comment Cyberhack aborde ce type de risque
Un audit technique utile ne devrait pas se limiter à lancer un scanner et à transmettre une liste de CVE.
Il faut savoir où se trouve la vulnérabilité, si le composant concerné est réellement exposé, quelle application métier est affectée et quelle correction appliquer en priorité.
C'est cette logique de visibilité et de priorisation que nous défendons chez Cyberhack.
L'objectif n'est pas de multiplier les alertes, mais de transformer un risque technique en décision compréhensible et exploitable.
Vous pouvez découvrir notre approche sur Cyberhack Platform.
Conclusion
Les vulnérabilités PHP révélées en octobre 2026 rappellent une réalité simple.
Un site disponible n'est pas nécessairement un site sécurisé.
Et un serveur annoncé comme « à jour » ne garantit pas que toutes ses applications utilisent des composants corrigés.
Commencez par identifier les versions réellement exécutées.
Vérifiez les correctifs.
Traitez en priorité les services exposés.
Et conservez des preuves des opérations réalisées.
Car lors d'un incident, la question ne sera pas seulement de savoir si une mise à jour était disponible.
Elle sera de savoir si votre entreprise avait réellement vérifié son exposition.
