En bref
Le 21 octobre 2026, le projet PHP a publié les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35 pour corriger deux failles critiques (CVE-2026-109618 et CVE-2026-109619) qui permettent à un inconnu d'exécuter du code sur un serveur sans s'identifier. Tout site écrit en PHP qui répond sur internet est concerné, dont la plupart des sites WordPress. La seule vraie protection est la mise à jour : demandez à votre hébergeur ou à votre prestataire de confirmer qu'elle est faite.
La plupart des dirigeants de PME n’ont jamais entendu parler de PHP. Pourtant, si votre site tourne sous WordPress, comme une très large part des sites vitrines, c’est PHP qui le fait fonctionner sur le serveur, à chaque visite.
Le 21 octobre 2026, le projet PHP a publié un correctif d’urgence pour deux failles jugées critiques, surnommées « PHP2Shell ». Elles permettent à un inconnu, sans mot de passe, de faire exécuter ses propres commandes par le serveur qui héberge votre site. Le message des développeurs tient en deux mots : mettez à jour.
Pour qui c'est important : toutes les entreprises dont le site, la boutique en ligne ou un outil annexe (réservation, espace client, devis) est écrit en PHP. C'est le cas de WordPress, de nombreuses boutiques en ligne et de beaucoup de sites faits sur mesure il y a quelques années.
Ce qui a été annoncé le 21 octobre
Le 20 octobre 2026, le projet PHP a prévenu qu’une mise à jour de sécurité critique arrivait. Le lendemain, il a publié son avis, intitulé « Critical remote code execution vulnerabilities, update now » (« failles critiques d’exécution de code à distance, mettez à jour maintenant ») (PHP, avis de sécurité du 21 octobre 2026).
Les deux failles portent les numéros CVE-2026-109618 et CVE-2026-109619. Elles permettent d’exécuter du code à distance sans être identifié, avec les droits du compte qui fait tourner PHP. Leur note de gravité est de 9,2 sur 10 (AlmaLinux, 21 octobre 2026 ; Datadog Security Labs, 23 octobre 2026).
Le Centre canadien pour la cybersécurité a publié le même jour une alerte officielle. Il précise que toute installation de PHP qui répond à des requêtes web est exposée, quelle que soit la façon dont PHP est branché au serveur, et que des démonstrations d’attaque sont déjà publiques (Centre canadien pour la cybersécurité, alerte AL26-026, 21 octobre 2026, mise à jour le 23 octobre).
| Version de PHP sur votre serveur | Version corrigée |
|---|---|
| 8.5 | 8.5.12 ou plus récente |
| 8.4 | 8.4.27 ou plus récente |
| 8.3 | 8.3.36 ou plus récente |
| 8.2 | 8.2.35 ou plus récente |
| 8.1, 8.0, 7.4 et plus anciennes | Plus suivies par le projet PHP : correctif minimal à obtenir de l’hébergeur, ou passage à une version suivie |
Source : PHP, avis de sécurité du 21 octobre 2026.
Un point important : les hébergeurs et les éditeurs de systèmes appliquent souvent le correctif sans changer le numéro de version affiché (AlmaLinux, 21 octobre 2026). Un « 8.3.33 » dans votre espace client ne veut donc pas forcément dire que rien n’a été fait. C’est une raison de plus pour poser la question directement.
Pourquoi ça concerne une PME, même petite
On imagine souvent que les pirates visent les grandes entreprises. Ce type de faille fonctionne autrement : des programmes parcourent internet à la recherche de serveurs pas encore à jour, sans se soucier de qui est derrière. Un site de boutique de vêtements, de restaurant ou de producteur en vente directe est une cible aussi intéressante qu’une autre, parce qu’il sert à envoyer du spam, à héberger des pages frauduleuses ou à rebondir vers d’autres serveurs.
Les conséquences pour vous sont concrètes :
- le site affiche des pages ou des liens qui ne sont pas les vôtres, et Google peut finir par le signaler comme dangereux ;
- les données de vos clients (formulaires de contact, comptes, commandes) peuvent être copiées ;
- le site doit être nettoyé ou reconstruit, ce qui coûte plus cher qu’une mise à jour faite à temps.
Si des données clients ont pu fuiter : le RGPD impose de prévenir la CNIL dans les 72 heures après avoir pris connaissance d'une violation de données personnelles qui présente un risque pour les personnes. Nous avons résumé ces règles dans l'article sur le RGPD pour le site d'une PME.
Vérifier votre situation en quatre questions
1. Votre site utilise-t-il PHP ? Si c’est un WordPress, oui. Pour un autre outil, la réponse est dans votre contrat ou auprès de celui qui a fait le site.
2. Qui gère le serveur ? Sur un hébergement mutualisé (vous partagez un serveur avec d’autres clients), c’est l’hébergeur qui met PHP à jour. Sur un serveur privé ou dédié, c’est votre prestataire, ou vous-même si personne n’a été désigné.
3. Quelle version tourne aujourd’hui ? Elle apparaît le plus souvent dans l’espace client de l’hébergeur, dans une rubrique du type « Configuration PHP ». Comparez-la au tableau ci-dessus, en gardant en tête que le correctif a pu être appliqué sans changer le numéro.
4. Avez-vous une confirmation écrite ? Un message de l’hébergeur ou du prestataire qui dit « le correctif du 21 octobre est appliqué sur votre site » vaut mieux que toutes les suppositions.
Ce qu’il faut demander à votre prestataire
Un message simple suffit. Demandez-lui :
- de confirmer que la version de PHP du serveur intègre le correctif du 21 octobre 2026 ;
- si votre site tourne encore en PHP 8.1 ou plus ancien, un plan pour passer à une version suivie, avec la liste des extensions ou des thèmes à adapter ;
- de vérifier qu’aucun signe d’intrusion n’est apparu depuis la mi-octobre : comptes administrateurs inconnus, fichiers ajoutés, redirections. Des éditeurs de sécurité ont signalé des tentatives d’attaque quelques jours avant l’annonce publique (Datadog Security Labs, 23 octobre 2026) ;
- de vérifier que la sauvegarde la plus récente fonctionne, pour pouvoir revenir en arrière si quelque chose cloche.
Si vous n’avez pas de contrat qui couvre ce genre de mise à jour, c’est exactement le rôle d’un contrat de maintenance. Et si plus personne ne sait qui a accès à votre hébergement, l’article sur récupérer son site quand on change de prestataire explique comment reprendre la main.
Le bon réflexe : notez quelque part qui gère votre hébergement, comment s'y connecter et quelle version de PHP tourne. La prochaine alerte de ce genre se réglera alors en un message au lieu d'une demi-journée de recherches.
Les réglages de secours ne remplacent pas la mise à jour
L’avis du projet PHP décrit des réglages qui réduisent le risque quand la mise à jour est impossible tout de suite, mais il est clair : aucun ne protège complètement, la mise à jour est le seul choix sûr (PHP, avis de sécurité du 21 octobre 2026). Le 23 octobre, une troisième faille, plus difficile à exploiter, a été signalée ; l’un des réglages déjà conseillés pour la deuxième faille la neutralise en attendant le prochain correctif (Centre canadien pour la cybersécurité, mise à jour du 23 octobre 2026).
Pour un site vitrine d’entreprise, ces réglages relèvent de l’hébergeur ou du prestataire, pas de vous. Votre rôle est de vous assurer que quelqu’un s’en occupe.
Et si votre site est trop ancien ?
C’est le cas le plus délicat : un site construit il y a des années, avec des extensions abandonnées, qui ne fonctionne plus si l’on passe PHP à une version récente. Le correctif minimal publié pour les anciennes versions peut dépanner, mais il ne règle pas le fond : le site restera fragile à la prochaine alerte.
C’est souvent le moment de se poser la question d’une refonte. Un site professionnel avec un vrai travail de référencement se situe entre 2 000 et 2 500 € HT ; il part sur une base à jour, et il peut même se passer de PHP sur le serveur quand il s’agit d’un site vitrine, ce qui supprime ce type de risque. Les autres points de base (sauvegardes, accès, mises à jour) sont détaillés dans l’article sur la sécurité du site web d’une PME.
En résumé
Le 21 octobre 2026, PHP a corrigé deux failles critiques qui permettent de prendre la main sur un serveur à distance. Les sites WordPress et tous les sites écrits en PHP sont concernés. Les versions sûres sont 8.5.12, 8.4.27, 8.3.36 et 8.2.35, ou une version plus ancienne corrigée par votre hébergeur.
Ce que vous avez à faire tient en un message : demander à votre hébergeur ou à votre prestataire de confirmer par écrit que le correctif est appliqué, et qu’aucune trace d’intrusion n’a été trouvée.
Si vous voulez un état des lieux complet de votre site, technique compris, c’est le travail d’un audit. Si le sujet est de repartir sur une base saine, on en parle sur la page création de site, et les budgets sont détaillés sur la page tarifs.
Sources : PHP, « Security advisory: Critical remote code execution vulnerabilities, update now », 21 octobre 2026 (php.net, archive 2026) ; Centre canadien pour la cybersécurité, alerte AL26-026 « Vulnérabilités critiques touchant PHP », 21 octobre 2026, mise à jour 1 du 23 octobre 2026 ; AlmaLinux, « php2shell (CVE-2026-109618, CVE-2026-109619): Patched PHP packages released », 21 octobre 2026 ; Datadog Security Labs, « PHP2Shell: Critical vulnerabilities in PHP », mis à jour le 23 octobre 2026.
