PHP prépare une mise à jour de sécurité exceptionnelle pour le 21 octobre 2026, à 16 h en France métropolitaine. Elle doit corriger deux vulnérabilités critiques, chacune notée 9,2/10. Voici les faits vérifiés, les incertitudes et les actions à préparer pour vos sites WordPress, boutiques WooCommerce et serveurs.
Point de situation : 21 octobre 2026, à 9 h 47, heure de Paris. Les sources consultées annoncent encore une publication à venir. Les versions vulnérables, les versions corrigées et les conditions techniques devront être vérifiées dans le bulletin publié avec les correctifs.
Deux failles critiques dans PHP : ce que l’on sait
Le 20 octobre, l’équipe de sécurité PHP a publié une annonce préalable de mise à jour critique. La publication est programmée le mercredi 21 octobre 2026 à 14 h UTC, soit 16 h à Paris.
Le projet confirme deux vulnérabilités et leur note de sévérité. En revanche, son annonce initiale ne précise ni les composants concernés ni les configurations nécessaires à leur exploitation. Elle réserve ces informations à la publication des correctifs.
| Point à vérifier | État des informations |
|---|---|
| Nombre de vulnérabilités | Deux, selon l’équipe PHP. |
| Sévérité annoncée | 9,2/10 pour chacune, selon CVSS v4.0. |
| Publication prévue | 21 octobre 2026 à 14 h UTC, soit 16 h à Paris. |
| Identifiants mentionnés par le CERT-EU | CVE-2026-109618 et CVE-2026-109619. |
| Risque rapporté | Exécution de code à distance ; modalités techniques à confirmer. |
| Versions vulnérables et corrigées | Liste officielle attendue avec la publication PHP. |
PHP pourrait également avancer cette publication si des détails devenaient publics ou si des signes d’exploitation apparaissaient. Par conséquent, l’horaire annoncé constitue un rendez-vous de suivi, pas une période pendant laquelle attendre sans préparer ses systèmes.
PHP2Shell, CVE et exécution de code : distinguer les niveaux de confirmation
L’avis de sécurité 2026-018 du CERT-EU mentionne les identifiants CVE-2026-109618 et CVE-2026-109619. Il relaie un risque d’exécution de code à distance, à partir d’informations ayant circulé avant la publication technique.
Le nom « PHP2Shell » circule également dans les communications de sécurité. Toutefois, un nom médiatique ne définit ni le périmètre exact d’une faille ni sa facilité d’exploitation. Pour décider quelles machines corriger, les bulletins PHP et ceux des fournisseurs restent les références.
Une exécution de code à distance permet, lorsque les conditions d’exploitation sont réunies, de faire exécuter du code sur le système visé. Les conséquences dépendent notamment des droits du processus compromis et de son isolation.
Par exemple, un processus PHP disposant d’accès aux fichiers d’un site peut présenter un risque pour son intégrité. Des identifiants accessibles depuis ce processus peuvent aussi élargir les conséquences. Cela ne signifie pas automatiquement que l’attaquant obtient les droits administrateur du serveur.
Le score CVSS ne suffit pas à déduire le scénario d’attaque. Sans vecteur complet ni description technique, impossible d’affirmer qu’une simple requête suffit dans toutes les configurations. Le guide CVSS v4.0 de FIRST distingue d’ailleurs sévérité technique, contexte d’exposition et facteurs de menace.
Quelles versions de PHP faut-il surveiller ?
À ce stade, il faut distinguer les branches maintenues des versions effectivement vulnérables. La politique officielle de support PHP indique quelles branches bénéficient encore de correctifs. Elle ne constitue pas une matrice d’exposition à ces deux failles.
| Branche | Situation au 21 octobre 2026 | Fin du support de sécurité officiel |
|---|---|---|
| PHP 8.2 | Correctifs de sécurité uniquement. | 31 décembre 2026. |
| PHP 8.3 | Correctifs de sécurité uniquement. | 31 décembre 2027. |
| PHP 8.4 | Support actif. | 31 décembre 2028. |
| PHP 8.5 | Support actif. | 31 décembre 2029. |
| PHP 8.1 et branches antérieures | Fin du support officiel PHP. | Échéance dépassée ; vérifier un éventuel support fournisseur. |
Le CERT-EU évoque une exposition potentiellement très ancienne, jusqu’aux générations PHP 5. Cette indication reste provisoire. Elle justifie d’inventorier les installations anciennes, sans présenter toutes les versions historiques comme officiellement vulnérables.
Par ailleurs, une distribution Linux peut rétroporter un correctif dans son propre paquet. Le numéro affiché par PHP ne raconte alors pas toute l’histoire. Vérifiez la révision complète du paquet et le bulletin de votre fournisseur avant de conclure.
WordPress et WooCommerce : le correctif relève de l’hébergement
WordPress et WooCommerce exécutent du code PHP côté serveur. Il faut donc vérifier leur environnement d’exécution lorsque PHP publie une alerte critique. Cependant, utiliser PHP ne prouve pas que chaque site remplit les conditions d’exploitation de ces vulnérabilités.
Mettre à jour WordPress ou une extension ne remplace pas la mise à jour de PHP. Le correctif doit atteindre l’interpréteur utilisé par votre hébergement. Selon votre infrastructure, cette responsabilité revient à l’hébergeur, à l’infogérant ou à l’administrateur système.
Sur un hébergement mutualisé, demandez quelle version complète sera déployée et comment sa correction sera confirmée. Sur un VPS, contrôlez chaque branche installée. Enfin, dans une infrastructure conteneurisée, vérifiez les images et les instances réellement exécutées.
Une boutique WooCommerce mérite ensuite une validation fonctionnelle ciblée : panier, commande, paiement en environnement de test, espace client et tâches planifiées. Pour organiser ces contrôles durablement, un audit technique WordPress permet de documenter les dépendances et les points sensibles.
Avant la publication : préparer une intervention courte et vérifiable
1. Inventorier les environnements PHP
Commencez par les sites publics, puis examinez les préproductions, sous-domaines, interfaces d’administration et applications oubliées. Un ancien outil accessible depuis Internet mérite autant d’attention que le site principal.
Pour chaque application, relevez son responsable, son hébergement, sa branche PHP, son mode d’exécution et ses sources de paquets. Identifiez également les traitements persistants et les tâches planifiées qui utilisent PHP.
2. Vérifier les sauvegardes et les accès
Préparez une sauvegarde des données et de la configuration, ainsi qu’un accès au serveur indépendant de WordPress. Vérifiez surtout la procédure de restauration. Une sauvegarde présente dans une liste n’a pas encore démontré qu’elle fonctionne.
Pour WooCommerce, prévoyez la conservation des nouvelles commandes pendant toute intervention. Restaurer une base ancienne sur une boutique active peut supprimer les ventes intervenues depuis la sauvegarde.
3. Préparer la chaîne de déploiement
Vérifiez les dépôts configurés et les éventuels paquets bloqués. Préparez ensuite les contrôles de configuration et les tests fonctionnels. Dès publication, comparez les versions disponibles au bulletin officiel avant toute installation.
Évitez de transformer cette intervention en migration générale. Si votre branche reçoit un correctif, une mise à jour ciblée réduit les changements simultanés. En revanche, une branche abandonnée exige un plan de migration ou une solution de support explicitement confirmée.
Vérifier PHP sur un serveur Debian ou Ubuntu
Les commandes suivantes servent à l’inventaire. Elles ne constituent pas un correctif et ne déterminent pas, seules, la vulnérabilité du serveur. Leur interprétation dépend du bulletin PHP et du fournisseur des paquets.
# Version et configuration de PHP en ligne de commande.
php -v
php --ini
# Paquets PHP installés et versions complètes.
dpkg-query -W -f='${binary:Package}\t${Version}\n' 'php*'
# Services PHP-FPM actuellement exécutés.
systemctl list-units --type=service --state=running 'php*-fpm.service'Langage du code : PHP (php)La documentation des options PHP décrit notamment -v et --ini. Attention : ces commandes interrogent le binaire de votre terminal. Votre serveur web peut utiliser une autre branche et un autre fichier de configuration.
Dans WordPress, consultez aussi Outils → Santé du site → Informations → Serveur. Rapprochez cette information du pool PHP-FPM réellement associé au domaine et de son paquet. Évitez de laisser un fichier phpinfo() accessible publiquement.
Pour examiner les versions proposées par les dépôts, voici un exemple limité à PHP 8.3. Adaptez les noms à votre installation :
# Actualiser les métadonnées des dépôts configurés.
sudo apt update
# Comparer les versions installées et candidates.
apt-cache policy php8.3-common php8.3-cli php8.3-fpm
# Simuler une mise à jour ciblée, sans installation.
sudo apt-get --simulate install --only-upgrade \
php8.3-common php8.3-cli php8.3-fpmLangage du code : CSS (css)Une version candidate n’est pas nécessairement une version corrigée. Vérifiez son statut dans le bulletin fournisseur. Examinez aussi les extensions installées, les dépendances et toutes les autres branches utilisées avant de construire votre commande d’installation.
Après l’installation : vérifier les processus, puis les applications
Installer de nouveaux fichiers ne garantit pas que tous les processus exécutent immédiatement le nouveau code. Prévoyez le redémarrage des services concernés selon les consignes du fournisseur, puis vérifiez leur état.
Sur PHP-FPM, contrôlez la configuration avant l’opération. Ensuite, vérifiez le démarrage des pools et l’absence d’erreurs nouvelles. La documentation PHP-FPM détaille le rôle de ce gestionnaire de processus.
Si Apache charge PHP comme module, c’est le service Apache qui doit reprendre le code corrigé. Pour les conteneurs, reconstruisez ou récupérez l’image corrigée, puis recréez les instances. Pensez aussi aux workers PHP persistants.
- Vérifiez la version du paquet et la confirmation du correctif par son fournisseur.
- Contrôlez le runtime web, les traitements CLI et les différents nœuds de l’infrastructure.
- Testez une page dynamique, la connexion, les formulaires et les fonctions métier essentielles.
- Surveillez les erreurs HTTP, les journaux applicatifs et les tâches en arrière-plan.
- Consignez les versions déployées, l’heure de l’intervention et les vérifications effectuées.
Une page servie depuis un cache ne valide pas PHP. De même, vider OPcache ou le cache WordPress ne remplace pas le chargement du moteur corrigé.
Que faire si le correctif n’est pas encore disponible ?
Le CERT-EU recommande de préparer une correction immédiate. Lorsque celle-ci n’est pas possible, il invite à envisager l’isolement des applications exposées à Internet. Cette décision doit tenir compte de l’exposition réelle et des informations techniques disponibles.
Concrètement, demandez d’abord un délai précis à votre hébergeur. Si nécessaire, restreignez l’accès en amont du runtime PHP : filtrage réseau, contrôle d’accès sur le frontal ou page statique servie sans exécuter l’application.
Un mode maintenance WordPress peut continuer à exécuter PHP. Il ne démontre donc pas que l’application est isolée. Vérifiez également les accès directs au serveur d’origine lorsqu’un CDN ou un proxy protège le domaine public.
Un WAF peut compléter la protection si son fournisseur confirme une règle pertinente. En revanche, sans description technique complète, aucune règle générique ne permet de promettre une couverture totale. Même logique pour les changements de configuration présentés comme des solutions miracles.
Mettre à jour ne remplace pas une recherche de compromission
Si votre site présente déjà des anomalies, traitez-les séparément. Un correctif ferme une vulnérabilité ; il ne supprime pas nécessairement les fichiers, comptes ou mécanismes de persistance déposés auparavant.
Conservez les journaux, relevez les modifications suspectes et examinez les accès inhabituels. Sur WordPress, vérifiez notamment les administrateurs inconnus, les fichiers inattendus et les tâches ajoutées. Ces contrôles généraux ne constituent pas des indicateurs spécifiques à ces deux CVE.
Enfin, ne confondez pas absence de symptôme et absence d’intrusion. Si une compromission est établie, prévoyez une restauration maîtrisée et le renouvellement des secrets exposés depuis un environnement sain.
Questions fréquentes sur cette alerte PHP
Mon site WordPress est-il automatiquement vulnérable ?
Il faut vérifier son environnement PHP. Toutefois, l’utilisation de WordPress ne suffit pas à établir l’exploitabilité. Les versions et conditions concernées doivent être confirmées dans le bulletin technique.
Dois-je changer de branche PHP ?
Pas nécessairement si votre branche maintenue reçoit le correctif. En revanche, une branche hors support nécessite une migration ou une confirmation explicite de couverture par votre fournisseur.
Un plugin de sécurité peut-il corriger PHP ?
Le correctif doit être appliqué au runtime PHP. Une extension peut contribuer à la surveillance ou au filtrage, mais elle ne remplace pas cette mise à jour.
Comment savoir si mon hébergeur a terminé ?
Demandez la version complète déployée, la référence du bulletin et la confirmation du redémarrage des processus concernés. Vérifiez ensuite le site et ses traitements. Une annonce générale de maintenance ne suffit pas à documenter votre installation.
Sources et suivi des correctifs
Les sources suivantes permettent de suivre l’annonce, les avis de sécurité et la maintenance des branches PHP. Les conseils de déploiement de cet article constituent une procédure générale ; ils devront être adaptés aux précisions du bulletin technique.
