La question revient à chaque faille. Le 21 octobre 2026, le projet PHP a publié des correctifs pour deux failles graves ; ce cas sert d'exemple tout au long de l'article, mais la méthode vaut pour la prochaine alerte.
Pourquoi la version de PHP vous concerne, même sans être technicien
Quand une faille touche PHP, elle touche le moteur du site, quel que soit le thème ou le soin apporté aux extensions. Les deux failles corrigées le 21 octobre 2026 ont été notées 9,2 sur 10 et permettaient, dans certaines configurations, d'exécuter du code sur le serveur sans aucun identifiant. Le CERT-EU, l'équipe de réponse aux incidents des institutions européennes, a conseillé de mettre à jour immédiatement et, faute de pouvoir le faire, d'isoler les sites exposés à Internet.
Ces failles concernaient toute installation de PHP qui répond à des visiteurs, quel que soit le mode de fonctionnement du serveur. Les réglages de contournement publiés en attendant réduisaient certains chemins d'attaque ; le projet PHP et le CERT-EU ont été clairs : seule la mise à jour corrige.
Comment lire le bon numéro de version
Un numéro de PHP compte trois nombres. Dans 8.3.36, les deux premiers (8.3) désignent la branche, le dernier (36) le niveau de correctif. Les correctifs de sécurité sortent sous forme de nouveaux numéros dans chaque branche encore maintenue. Le 21 octobre 2026, ce furent 8.5.12, 8.4.27, 8.3.36 et 8.2.35.
Une installation en 8.3.25 et une autre en 8.3.36 sont toutes deux « en PHP 8.3 ». Seule la seconde contient les correctifs du 21 octobre. C'est là que se trouve le piège : dans l'espace client d'un hébergeur, on choisit une branche dans un menu ; le niveau de correctif, lui, n'y apparaît pas toujours.
Où lire le numéro complet :
- WordPress : Outils, Santé du site, onglet Informations, section Serveur, ligne « Version de PHP ».
- Joomla : Système, Informations système.
- Autre site : demandez-le à la personne qui a fait le site ou à l'hébergeur, par écrit.
Comparez ensuite avec la page des versions sur php.net, qui liste les branches maintenues et la dernière version publiée de chacune.
Quelles versions sont encore maintenues ?
Chaque branche de PHP reçoit tous les correctifs pendant deux ans, puis les seuls correctifs de sécurité critiques pendant deux ans encore. Ensuite, plus rien. Voici l'état lu sur php.net le 22 octobre 2026 :
| Branche | Correctifs de sécurité jusqu'au | Version corrigée du 21 octobre 2026 |
|---|---|---|
| 8.5 | 31 décembre 2029 | 8.5.12 |
| 8.4 | 31 décembre 2028 | 8.4.27 |
| 8.3 | 31 décembre 2027 | 8.3.36 |
| 8.2 | 31 décembre 2026 | 8.2.35 |
| 8.1 et avant (dont PHP 7) | Fin de vie | Aucune version du projet PHP |
Deux conséquences pour un dirigeant. Si votre site est en 8.2, il est dans sa dernière ligne droite : la branche ne recevra plus rien après le 31 décembre 2026, et c'est le moment de demander la date de passage à une branche plus récente. S'il est en PHP 7 ou en 8.1, le projet PHP ne publie plus de version pour lui. Pour les failles du 21 octobre, l'équipe de PHP a bien mis à disposition des correctifs minimaux pour 7.4, 8.0 et 8.1, mais à destination de ceux qui compilent PHP eux-mêmes. Certains hébergeurs vendent un support prolongé des vieilles branches : il fait gagner du temps, il ne remplace pas la migration.
Qui doit faire la mise à jour : vous ou votre hébergeur ?
Cela dépend de votre offre, et c'est la question que beaucoup de dirigeants découvrent le jour d'une alerte. L'équipe de sécurité de Drupal l'a rappelé dans son avis du 21 octobre : les propriétaires de sites sont responsables de la sécurité de leur plateforme d'hébergement, et quand l'hébergeur gère PHP, il faut suivre ses communications.
| Votre hébergement | Qui installe les correctifs de PHP | Ce que vous vérifiez |
|---|---|---|
| Mutualisé (vous choisissez la version dans un menu de l'espace client) | En général l'hébergeur, pour la branche que vous avez choisie. IONOS l'écrit dans son aide pour ses versions récentes. | La branche choisie est-elle maintenue ? Le correctif est-il installé ? |
| Infogéré (un prestataire administre le serveur pour vous) | Le prestataire, si le contrat le prévoit | Le contrat cite-t-il les mises à jour de sécurité, avec un délai ? |
| Serveur virtuel ou dédié que personne n'administre officiellement | Vous, ou la personne à qui vous l'avez confié | Qui a la main sur le serveur, et qui a été prévenu ? |
Le cas qui inquiète le plus est le troisième : un serveur loué il y a quelques années par un ancien prestataire, que plus personne ne surveille. Si vous ne savez pas répondre à « qui a la main ? », c'est la première chose à régler.
Une précision utile : PHP ne se cache pas seulement derrière votre site vitrine. Une boutique en ligne, un extranet, un logiciel métier hébergé chez un éditeur peuvent aussi l'utiliser. Le CERT-EU renvoie vers une liste tenue par le centre de cybersécurité néerlandais (NCSC-NL) qui recense les logiciels tiers embarquant PHP. Pour ceux-là, la question va à l'éditeur.
Que demander à son hébergeur : le message prêt à envoyer
Envoyez-le par le support ou par mail, pour garder une réponse écrite. Adaptez les numéros de version à la prochaine alerte.
Objet : version de PHP et correctifs de sécurité de mon hébergement
Bonjour,
Pour le site [adresse du site] (contrat [référence]), pouvez-vous me répondre par écrit sur les points suivants :
- Quelle version exacte de PHP est utilisée, numéro complet compris (par exemple 8.3.36), pour ce site et pour chaque autre site ou sous-domaine du contrat ?
- Les correctifs de sécurité publiés par le projet PHP sont-ils installés automatiquement sur mon offre, et sous quel délai après leur publication ?
- Les correctifs publiés le 21 octobre 2026 (8.5.12, 8.4.27, 8.3.36, 8.2.35) sont-ils installés sur mon hébergement, et depuis quelle date ?
- Ma branche de PHP est-elle encore maintenue, jusqu'à quand, et comment se passera le changement de branche ?
- Si ma version est en fin de vie : proposez-vous des correctifs, et que faut-il prévoir pour migrer ?
- Comment serai-je prévenu lors de la prochaine faille de PHP ?
Merci,
[Nom, fonction]
Les points 2 et 6 servent pour la suite : une fois que vous savez qui applique les correctifs et par quel canal vous êtes prévenu, la prochaine alerte se règle en lisant un mail.
Avant de changer de branche, trois précautions
Installer un correctif dans la même branche (de 8.3.25 à 8.3.36) ne change en principe pas le comportement du site. Changer de branche (de 7.4 à 8.3, par exemple) peut en revanche casser un vieux thème ou une extension. Avant :
- une sauvegarde complète, avec la date, et la certitude de savoir la restaurer ;
- WordPress ou Joomla, le thème et les extensions mis à jour d'abord ;
- un essai sur une copie du site quand l'hébergeur le permet, puis une vérification des pages qui comptent : formulaire de contact, prise de rendez-vous, paiement.
Un détail à connaître : certains hébergeurs, comme Infomaniak, ne permettent plus de revenir à une version vulnérable une fois le changement fait. La sauvegarde ne doit donc pas compter sur un retour en arrière de PHP.
Ce que nous avons vérifié chez nous
Nous avons posé la question à notre propre site le 22 octobre 2026. Il est construit avec Next.js, un outil JavaScript, et n'exécute pas de PHP : les failles du 21 octobre ne le concernaient pas. La démarche reste la même pour tout site : savoir sur quoi il tourne, qui le met à jour, et par où arrive l'alerte.
Nous avons aussi lu en entier, le 22 octobre 2026, quatre pages françaises parmi les premiers résultats d'une recherche sur la mise à jour de PHP : l'aide de WordPress en français, un guide WordPress spécialisé et les aides de deux hébergeurs. Aucune des quatre ne dit de vérifier le numéro complet plutôt que la branche. Deux proposent un message à envoyer à l'hébergeur, et les deux messages ne demandent qu'une branche minimale (7.4 dans l'un, branche désormais en fin de vie ; 8.3 dans l'autre) : ni le niveau de correctif, ni qui installe les correctifs, ni dans quel délai. C'est ce manque qui nous a fait écrire cet article.
Faut-il un agent IA pour surveiller ça ?
Pour un site, non. Une alerte de votre hébergeur, une ligne dans l'agenda chaque trimestre pour relire le numéro de version, et le message ci-dessus suffisent. Un agent de veille a du sens quand l'entreprise dépend de plusieurs logiciels et prestataires : il lit les avis de sécurité, repère ceux qui touchent vos outils et prépare le message à envoyer, qu'une personne relit avant l'envoi. Les règles d'accès à respecter dans ce cas sont détaillées dans notre article sur les accès à donner à un agent IA et dans les quatre questions à poser avant de brancher un agent IA sur vos outils.
Le suivi des outils qu'on installe, mises à jour comprises, fait partie de notre accompagnement. Et la liste de vos outils, avec la personne qui maintient chacun, est l'un des premiers documents que l'on écrit pendant un cadrage.
FAQ
Comment savoir quelle version de PHP utilise mon site ?
Sous WordPress : Outils, Santé du site, onglet Informations, section Serveur. Sous Joomla : Système, Informations système. Sinon, l'espace client de votre hébergeur indique la branche, pas toujours le numéro complet : demandez-le alors par écrit.
PHP 8.3 suffit-il pour être à jour ?
Non. 8.3 est une branche ; ce qui compte est le numéro complet. Après les correctifs du 21 octobre 2026, une installation en 8.3 doit être au moins en 8.3.36 pour corriger les deux failles publiées ce jour-là.
Est-ce à moi ou à mon hébergeur de mettre PHP à jour ?
Cela dépend de votre offre. Sur un hébergement mutualisé, l'hébergeur installe en général les correctifs de la branche que vous avez choisie ; sur un serveur que vous administrez, c'est à vous ou à votre prestataire. L'équipe de sécurité de Drupal le rappelle : la sécurité de la plateforme reste de la responsabilité du propriétaire du site.
Mon site est en PHP 7, que faire ?
Prévoir une migration vers une branche maintenue (8.2 ou plus récente au 22 octobre 2026). Les branches 8.1 et antérieures ne reçoivent plus de correctifs du projet PHP ; certains hébergeurs vendent un support prolongé, qui retarde la migration sans la remplacer.
Sources, toutes lues le 22 octobre 2026 : The PHP Foundation, « Today's PHP Security Release, and How We're Strengthening PHP Security », 21 octobre 2026 (thephp.foundation) · CERT-EU, avis de sécurité 2026-018 « Critical Vulnerabilities in PHP », 21 octobre 2026 (cert.europa.eu) · Drupal Security Team, PSA-2026-10-20, 21 octobre 2026 (drupal.org) · php.net, « Supported Versions » (php.net) · BleepingComputer, « PHP ships emergency patches for critical PHP2Shell flaws », Sergiu Gatlan, 21 octobre 2026 · WordPress.org, « Mettez à jour votre version de PHP » (fr.wordpress.org) · Documentation Joomla, « Site System Information » (docs.joomla.org) · IONOS Assistance, « Afficher ou changer la version de PHP » · Infomaniak, FAQ 2053 « Modifier la version de PHP d'un site ». Le relevé des quatre pages a été fait par Équipage IA le 22 octobre 2026. Aucun cas client n'est cité.