<p>Le CERT-FR signale, dans son avis du 31 juillet 2026, plusieurs vulnérabilités corrigées la veille dans toutes les branches maintenues de PHP,...
Une mise à jour de PHP ne fait pas la une. Elle mérite pourtant quelques minutes d'attention: PHP est le moteur qui fait tourner la plupart des sites vitrines, boutiques en ligne et intranets des petites entreprises. Les correctifs publiés le 30 juillet 2026 traitent notamment une injection SQL, c'est-à-dire une faille qui touche directement la base de données. Le CERT-FR a publié le 31 juillet 2026 l'avis CERTFR-2026-AVI-0952, au lendemain de la sortie des correctifs. Toutes les branches de PHP encore maintenues sont concernées: les versions 8.2.x antérieures à 8.2.33, 8.3.x antérieures à 8.3.33, 8.4.x antérieures à 8.4.24 et 8.5.x antérieures à 8.5.9.
Trois types de risques sont identifiés: une injection SQL, un déni de service et un problème de sécurité que l'éditeur n'a pas détaillé. Les références publiques associées sont CVE-2026-17543, CVE-2026-17544, CVE-2026-7260 et CVE-2026-9672.
Un point important pour ne pas surréagir: ni le CERT-FR ni l'éditeur ne signalent d'exploitation réelle à la date du 2 août 2026. Il s'agit d'un avis, pas d'une alerte, et la nuance compte dans la façon de prioriser. Ce statut peut évoluer: c'est la page du CERT-FR qui fait référence. Derrière chaque site un peu vivant, il y a une base de données: le catalogue produits, les comptes clients, les messages reçus via le formulaire de contact, les commandes. Une injection SQL consiste à détourner un champ de saisie ou un paramètre d'URL pour faire exécuter à cette base une instruction qui n'était pas prévue.
Concrètement, cela peut permettre de lire des données qui devaient rester privées, ou de les modifier. Sur une boutique en ligne, la base contient des coordonnées de clients: on entre alors dans le champ du RGPD, avec l'obligation de notification à la CNIL qui peut en découler lorsqu'une violation de données est caractérisée. Les conditions exactes de cette obligation relèvent de la doctrine de la CNIL, à vérifier sur son site ou avec votre conseil.
Le déni de service, lui, a un effet plus visible mais moins durable: le site devient indisponible. Pour un commerce dont les commandes passent par le web, l'impact est immédiat.
Le vrai sujet: savoir quelle version vous utilisez
La difficulté, pour une TPE ou une PME, n'est pas d'appliquer le correctif. C'est de savoir où elle en est. La version de PHP se décide au niveau de l'hébergement, pas au niveau du site. Une entreprise peut donc très bien avoir un WordPress parfaitement à jour, posé sur une version de PHP qui ne l'est plus depuis des mois.
Autre cas fréquent, et plus préoccupant que celui traité par cet avis: les sites encore hébergés sur PHP 8.1 ou une branche antérieure. Ces branches ne reçoivent plus de correctifs de sécurité. Les failles découvertes ensuite y restent ouvertes, sans perspective de mise à jour. 1. Identifier la version en place. Demander à votre prestataire ou à votre hébergeur la version de PHP utilisée par chacun de vos sites. Elle est le plus souvent affichée dans le panneau d'hébergement, à la rubrique consacrée à la version PHP.
2. Faire appliquer la version corrigée de votre branche. Soit 8.2.33, 8.3.33, 8.4.24 ou 8.5.9 selon le cas. En hébergement mutualisé, l'opération se fait généralement en quelques clics côté hébergeur.
3. Traiter en priorité les branches abandonnées. Si un site tourne encore en PHP 8.1 ou avant, la migration vers une branche supportée passe devant tout le reste: c'est le seul cas où aucun correctif n'arrivera jamais.
4. Tester avant de basculer la production. Un thème ou une extension ancienne peut cesser de fonctionner après une montée de version. Un environnement de préproduction évite de le découvrir devant les clients.
5. Sauvegarder, et vérifier la sauvegarde. Fichiers et base de données, avant l'opération. Une sauvegarde dont on n'a jamais testé la restauration n'est pas une sauvegarde.
6. Regarder en arrière une fois la mise à jour faite. Faire contrôler les journaux d'accès des semaines précédentes, à la recherche de requêtes anormales visant les formulaires et les URL de recherche.
Les numéros de version et les emplacements d'interface sont donnés à titre indicatif et varient selon l'hébergeur. Toute montée de version doit être validée sur un environnement de test avant d'être appliquée en production. Aucune exploitation n'était signalée au 2 août 2026: il n'y a donc pas d'urgence à agir dans l'heure, mais il y a un intérêt réel à savoir, une fois pour toutes, sur quelle version de PHP tournent vos sites. Cette question posée à votre hébergeur prend cinq minutes et vous servira à chaque avis suivant.
- CERT-FR (ANSSI), avis CERTFR-2026-AVI-0952, publié le 31 juillet 2026.
- PHP Group, journal des modifications des versions 8.2.33, 8.3.33, 8.4.24 et 8.5.9, publiées le 30 juillet 2026.
Synthèse rédactionnelle originale de TICLIC, établie à partir de la veille du 3 août 2026. Les numéros de version et les références CVE proviennent de l'avis du CERT-FR et des bulletins de l'éditeur consultés le 2 août 2026; ils n'ont pas fait l'objet d'une vérification indépendante complémentaire au moment de la rédaction. L'absence d'exploitation connue est un état daté au 2 août 2026: consultez la page du CERT-FR pour l'état courant.