EN BREF
Les failles PHP critiques suivies par le CERT-FR ont fait l’objet d’une nouvelle actualisation le 27 octobre, avec des tentatives d’exploitation signalées contre certains déploiements. Les TPE et PME qui exploitent un site Internet doivent vérifier la version réellement utilisée, organiser la correction avec leur prestataire et contrôler le service après intervention.
L’ESSENTIEL EN 3 POINTS
- Les vulnérabilités concernent plusieurs branches de PHP, notamment les versions anciennes qui ne reçoivent plus de correctifs de sécurité.
- Le CERT-FR recommande d’appliquer les correctifs disponibles ; pour une version non maintenue, il faut préparer une migration vers une branche supportée.
- Une PME doit coordonner sauvegarde, test, mise à jour et contrôle du site au lieu de modifier précipitamment son serveur de production.
Les failles PHP critiques signalées en octobre ne sont plus un sujet réservé aux équipes techniques. Le CERT-FR indique désormais avoir observé des tentatives d’exploitation visant des déploiements spécifiques. Pour une TPE ou une PME qui dépend de son site vitrine, de sa boutique ou d’un espace client, le bon réflexe consiste à lancer un contrôle structuré sans improviser une mise à jour en pleine production.
Pourquoi l’alerte devient plus urgente pour les petites entreprises
Cybermalveillance.gouv.fr a déclenché une AlerteCyber le 22 octobre 2026 après la correction de deux vulnérabilités critiques dans PHP. Le service public cite plusieurs risques : prise de contrôle à distance, interruption du fonctionnement, espionnage, vol ou destruction de données. Les sites transactionnels, ceux qui manipulent des informations sensibles et ceux qui communiquent avec le système interne sont présentés comme particulièrement exposés.
Le bulletin du CERT-FR, mis à jour le 27 octobre, apporte un élément supplémentaire : des tentatives d’exploitation ont été constatées contre certains déploiements. Cela ne signifie pas que tous les sites PHP sont compromis, mais attendre une panne ou une alerte de l’hébergeur pour vérifier sa configuration devient un pari inutile.
Le premier contrôle : connaître la version réellement exécutée
Une entreprise peut utiliser WordPress, PrestaShop ou une application métier sans savoir quelle version de PHP fonctionne derrière. L’information se trouve généralement dans le panneau d’hébergement, dans l’outil d’administration du serveur ou auprès du prestataire qui assure la maintenance.
Les versions affectées mentionnées par l’alerte incluent les branches 5.x, 7.x, 8.0.x et 8.1.x, ainsi que les versions antérieures à 8.2.35, 8.3.36, 8.4.27 et 8.5.12 dans leurs branches respectives. PHP ne maintient plus plusieurs anciennes branches. Dans ce cas, installer un correctif isolé ne suffit pas : une migration doit être planifiée.
Le dirigeant n’a pas besoin d’effectuer lui-même cette opération. Il doit en revanche obtenir une réponse précise : version actuelle, version cible, date d’intervention, responsable désigné et moyen de retour arrière si une incompatibilité apparaît.
Ne cliquez pas sur “mettre à jour” sans filet de sécurité
Une mise à jour PHP peut révéler l’incompatibilité d’un thème, d’une extension ou d’un développement ancien. Ce risque fonctionnel ne justifie pas de conserver une version vulnérable ; il impose d’organiser l’intervention. Avant le changement, l’entreprise doit disposer d’une sauvegarde récente et restaurable, identifier les fonctions essentielles du site et prévoir un créneau de contrôle.
- Inventorier : noter l’hébergeur, la version PHP, le CMS, les extensions critiques et la personne qui possède les accès techniques.
- Sauvegarder : conserver les fichiers et la base de données, puis vérifier qu’une procédure de restauration existe réellement.
- Tester : utiliser si possible une copie de préproduction pour contrôler la boutique, les formulaires, le paiement, l’espace client et les tâches automatiques.
- Corriger : appliquer la version sécurisée recommandée par l’hébergeur ou migrer vers une branche maintenue avec l’aide du prestataire.
- Vérifier : relire les journaux d’erreurs, tester les parcours essentiels et confirmer que les sauvegardes continuent de s’exécuter.
Le message exact à envoyer à votre hébergeur ou mainteneur
Pour éviter une réponse vague, le dirigeant peut demander par écrit : « Quelle version de PHP exécute chacun de nos sites ? Est-elle concernée par l’alerte CERTFR-2026-ALE-014 ? Quel correctif ou quelle migration prévoyez-vous, à quelle date et avec quel contrôle après intervention ? »
Il faut aussi préciser les dépendances commerciales : prise de commande, paiement, réservation, génération de devis ou synchronisation avec un logiciel interne. Le prestataire peut alors prioriser les services dont l’arrêt aurait le plus d’impact, au lieu de traiter tous les sites de la même façon.
Si le site conserve des données sensibles, le contrôle technique doit s’inscrire dans une protection plus large. Wiiz a déjà détaillé les vérifications utiles pour rendre les fichiers illisibles en cas de vol. Une version PHP corrigée ne remplace ni la gestion des accès, ni les sauvegardes, ni la surveillance des événements inhabituels.
Ce que la PME doit obtenir avant de clore l’incident
Le dossier ne doit pas être considéré comme terminé à la réception d’un simple « c’est mis à jour ». L’entreprise doit conserver la version avant et après intervention, la date, le périmètre traité, les tests effectués et les éventuelles anomalies restantes. Pour un site géré par un tiers, cette trace permet aussi de vérifier que tous les environnements ont été couverts.
Face aux failles PHP critiques, la priorité n’est donc pas de multiplier les manipulations techniques. Elle est de transformer l’alerte en une séquence contrôlée : identifier, sauvegarder, corriger, tester et documenter. C’est cette discipline qui réduit à la fois le risque cyber et le risque d’interrompre une activité numérique essentielle.

