Failles PHP 2026 : le CERT-FR alerte, check-list de mise à jour pour votre site

Le 07 juillet 2026, le CERT-FR a publié l'avis CERTFR-2026-AVI-0843 : de multiples vulnérabilités touchent PHP, sur l'ensemble de ses branches actives. Les correctifs existent déjà, publiés le 02 juillet 2026 par l'éditeur : PHP 8.2.32, 8.3.32, 8.4.23 et 8.5.8. Si votre site tourne sous PHP, qu'il s'agisse d'un WordPress, d'un PrestaShop ou d'une application Symfony ou Laravel maison, cet avis vous concerne directement.

Un avis CERT-FR n'est pas le niveau d'urgence maximal (l'ANSSI réserve le terme « alerte » aux failles jugées les plus critiques ou activement exploitées), mais c'est tout de même un signal officiel qu'il ne faut pas laisser traîner. Chez CZSyn, ce type de publication déclenche systématiquement une vérification des versions PHP installées sur les sites que nous hébergeons et maintenons. Voici comment procéder de votre côté, sans jargon inutile.

Ce que dit, et ne dit pas, l'avis du CERT-FR

L'avis reste volontairement sobre sur le détail technique : le champ « Risque » y est renseigné comme « Non spécifié par l'éditeur ». En clair, l'équipe de sécurité de PHP n'a pas rendu publique la gravité exacte de chaque faille au moment de la sortie des correctifs, une pratique courante pour ne pas offrir de feuille de route aux attaquants qui liraient le changelog pour reconstruire un exploit. Deux références sont malgré tout associées à cet avis : CVE-2026-12184 et CVE-2026-14355. Sans description publique détaillée à ce stade, la seule attitude raisonnable est de traiter ces vulnérabilités comme à corriger sans délai, plutôt que d'attendre une clarification qui ne viendra peut-être jamais.

Quatre branches concernées, un seul jour de sortie

L'avis couvre l'intégralité des branches actives de PHP :

• PHP 8.2.x : vulnérable en dessous de la version 8.2.32
• PHP 8.3.x : vulnérable en dessous de la version 8.3.32
• PHP 8.4.x : vulnérable en dessous de la version 8.4.23
• PHP 8.5.x : vulnérable en dessous de la version 8.5.8

Ces quatre versions correctives ont toutes été publiées le même jour, le 02 juillet 2026. Un calendrier aussi synchronisé sur l'ensemble du tronc commun du langage indique généralement un correctif portant sur du code partagé entre les branches, plutôt qu'un bug isolé sur une seule version. Concrètement : quelle que soit la branche majeure que vous utilisez, si votre version est antérieure à celle listée ci-dessus, vous êtes concerné.

La check-list pour patcher votre serveur

Première étape, indispensable : identifier la version de PHP réellement exécutée en production, qui n'est pas toujours celle de votre environnement local.

Sur un serveur Linux avec accès SSH :

php -v

Sur un environnement conteneurisé, vérifiez la version de base dans votre Dockerfile :

FROM php:8.3-fpm

Sur Debian ou Ubuntu, si vous gérez le paquet PHP vous-même :

sudo apt update
sudo apt install --only-upgrade php8.3 php8.3-fpm php8.3-cli

Sur une distribution Red Hat, Alma ou Rocky Linux :

sudo dnf update php

Sur un hébergement mutualisé (cPanel, Plesk ou panneau propriétaire), la version de PHP se change en général depuis un sélecteur dédié dans l'interface d'administration, sans accès SSH. Si vous ne savez pas où le trouver, contactez directement votre hébergeur : c'est une opération de routine pour son support.

Une fois la mise à jour effectuée, revérifiez avec php -v et testez immédiatement les fonctionnalités critiques du site : formulaires, panier, connexion utilisateur. Ces correctifs restent des versions de patch (le dernier chiffre du numéro de version), pas des montées de version majeure : la compatibilité ascendante est en principe assurée, mais un test rapide reste la seule façon de s'en assurer réellement avant de passer au site suivant.

Pourquoi ne pas attendre la prochaine fenêtre de maintenance

PHP fait tourner une part très large du web francophone, via WordPress, PrestaShop, ou des frameworks comme Symfony et Laravel. Une vulnérabilité « non spécifiée par l'éditeur » ne veut pas dire une vulnérabilité mineure : elle veut surtout dire que l'information technique n'est pas encore publique, ce qui laisse justement le temps aux équipes sérieuses de patcher avant qu'un chercheur, ou un attaquant, ne publie une preuve de concept exploitant les CVE associées. Pour une PME, l'enjeu n'est pas seulement la faille en elle-même : c'est le délai entre la sortie du correctif et son application réelle sur le serveur de production. C'est précisément cette fenêtre que les scans automatisés ciblent en priorité.

Notre lecture chez CZSyn

Ce genre d'avis CERT-FR tombe plusieurs fois par an, et suit toujours le même schéma : peu de détail technique, mais une liste de versions précise à respecter. Notre recommandation ne change pas d'un avis à l'autre : automatisez la surveillance de la version PHP de vos serveurs, avec une alerte de monitoring qui se déclenche dès qu'une version obsolète est détectée, plutôt que de compter sur la lecture manuelle de chaque bulletin. Sur les infrastructures que nous opérons pour nos clients, la montée de version patch se fait en quelques minutes, sans interruption de service, grâce à un déploiement par bascule progressive. C'est cette automatisation, plus que la réactivité ponctuelle face à un avis isolé, qui protège réellement un site PHP dans la durée.

Sources primaires

• CERT-FR, avis CERTFR-2026-AVI-0843, « Multiples vulnérabilités dans PHP », 07 juillet 2026.
• PHP.net, journal officiel des modifications (ChangeLog-8.php).
• CVE.org, fiche CVE-2026-12184.
• CVE.org, fiche CVE-2026-14355.