Le 21 octobre 2026, l’équipe de PHP a publié des correctifs d’urgence pour deux failles critiques. Très vite, des attaques étaient déjà observées. PHP fait tourner une grande partie du web : la sécurité d’un site web n’est donc pas un sujet réservé aux grandes entreprises.
Cet article fait le point sur ce qui s’est passé, sur les raisons pour lesquelles cela concerne aussi une PME, et sur ce que nous vérifions chez Kayo, pour un site comme pour une application ou un SaaS.
La faille PHP2Shell : ce qui s’est passé
Deux vulnérabilités, référencées CVE-2026-109618 et CVE-2026-109619 et surnommées « PHP2Shell », ont été corrigées le 21 octobre 2026. Elles permettent à une personne sans compte, depuis Internet, d’exécuter du code sur le serveur qui fait tourner PHP. Le CERT-UE leur attribue un score de gravité (CVSS) de 9,2 sur 10.
Ce qu’on sait au 3 novembre 2026
- Les versions corrigées sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Toute version plus ancienne de ces branches est vulnérable.
- Les versions 8.1 et antérieures ne sont plus maintenues et ne reçoivent plus de mise à jour ordinaire. PHP a toutefois publié des correctifs minimaux pour les branches 7.4, 8.0 et 8.1, et certains hébergeurs fournissent leur propre correctif. La vraie solution reste de migrer vers une version maintenue.
- Toutes les installations PHP qui servent des pages web sont concernées, quel que soit le serveur utilisé (Apache, PHP-FPM, LiteSpeed…).
- Aucun réglage ne remplace la mise à jour : PHP indique qu’aucune modification de configuration ne corrige complètement ces failles.
Le temps pour agir est court. Des preuves de concept circulent selon le CERT-UE. La société watchTowr dit avoir observé des tentatives d’attaque dès le 21 octobre. Et le 26 octobre, l’agence américaine CISA a ajouté ces failles à son catalogue des vulnérabilités déjà exploitées. En Belgique, le Centre pour la Cybersécurité Belgique a lui aussi émis un avertissement et recommande de mettre à jour en priorité, ou de mettre hors ligne les systèmes vulnérables en attendant.
Le CERT-UE signalait aussi, le 23 octobre, un troisième identifiant (CVE-2026-115560) dont le détail n’était pas encore publié. Au 3 novembre, il n’a toujours ni correctif ni avis complet : en attendant, le CERT-UE conseille de désactiver l’option session.upload_progress. PHP estime que cette faille ne touche que des applications configurées de façon inhabituelle et que le risque est peu probable. La situation évolue vite : vérifiez toujours l’avis officiel de PHP avant d’agir.
Êtes-vous concerné ?
Si votre site tourne sur WordPress, sur une boutique ou sur un outil développé en PHP, la réponse est probablement oui. Beaucoup d’hébergements mutualisés fonctionnent aussi avec PHP, même quand le site lui-même n’est pas écrit dans ce langage. Trois questions pour vous situer :
- Quelle version de PHP tourne chez votre hébergeur ? Elle figure généralement dans son panneau de gestion.
- Qui applique les mises à jour : votre hébergeur, un prestataire, ou personne ?
- La version est-elle encore maintenue ? Les versions 8.1 et antérieures ne le sont plus, et PHP 8.2 ne recevra plus de correctifs de sécurité après le 31 décembre 2026, selon le calendrier officiel de PHP.
Chez Kayo, les sites que nous construisons reposent par défaut sur Next.js, et non sur PHP. Cette faille précise ne les concerne donc pas, sauf projet particulier bâti sur un CMS PHP. Cela ne les rend pas invulnérables pour autant : les outils qu’ils utilisent publient eux aussi des correctifs de sécurité, et il faut les appliquer.
Pourquoi sécuriser un site, une application ou un SaaS
Une faille comme celle-ci n’est pas un cas isolé. Elle illustre une tendance.
- Les failles non corrigées sont devenues la première porte d’entrée. Selon le rapport 2026 de Verizon, l’exploitation d’une vulnérabilité est à l’origine de 31 % des intrusions analysées, devant le vol d’identifiants.
- La Belgique n’est pas épargnée. Le Centre pour la Cybersécurité Belgique a reçu 588 signalements d’incidents chez des entreprises belges entre le 1er janvier et le 28 septembre 2026, soit plus que les 556 de toute l’année 2025, selon ITdaily.
- Les attaques sont automatisées. Des robots parcourent le web et testent les versions vulnérables, sans se soucier de la taille de l’entreprise.
Les conséquences d’une intrusion sont concrètes : site hors service, données de clients exposées, image abîmée auprès de vos clients. Si des données personnelles sont touchées, le RGPD peut imposer de prévenir l’Autorité de protection des données, en principe dans les 72 heures.
Appliquer un correctif prend généralement bien moins de temps que gérer un incident. C’est ce qui rend la prévention rentable.
Site, application, SaaS : mêmes réflexes, risques différents
- Un site vitrine : l’hébergement, les mises à jour du CMS et des extensions, les formulaires de contact, le certificat HTTPS.
- Une application ou un outil métier : les comptes, les droits d’accès de chacun et les données qui y circulent.
- Un SaaS : tout ce qui précède, plus l’isolation des données entre vos clients, les clés d’accès aux services tiers et les sauvegardes.
Plus un outil concentre de données, plus le niveau d’exigence monte. C’est pourquoi nous adaptons les protections au projet, au lieu d’appliquer le même réglage partout.
Ce que nous mettons en place chez Kayo
Avant chaque mise en production, nous passons une check-list de sécurité point par point et corrigeons les points ouverts avant livraison. Selon la nature du projet, elle vérifie notamment :
Avant la mise en ligne
- Les bases : HTTPS actif avec redirection forcée, domaine et DNS correctement configurés, protection des e-mails du domaine (SPF, DKIM, DMARC) s’il envoie des messages.
- Les accès : mots de passe forts, double authentification par application plutôt que par SMS quand le choix existe, aucun identifiant par défaut laissé actif.
- Le code et les secrets : aucune clé d’accès dans l’historique du code, alertes automatiques sur les dépendances vulnérables.
- Les formulaires et les API : validation côté serveur, limitation des tentatives, anti-robot sur les formulaires à fort enjeu, pages d’erreur sans trace technique.
- Les protections du navigateur : en-têtes de sécurité qui limitent ce qu’une page peut charger ou afficher.
- Les données : isolation des données personnelles au niveau de la base, accès à la base uniquement depuis le serveur.
- Les sauvegardes : sauvegarde automatique, copie hors du compte principal, restauration testée au moins une fois.
Une fois le site en ligne, la sécurité demande un suivi. C’est le rôle de la maintenance de site web : mises à jour, sauvegardes et surveillance. Dans nos packs, la sécurité, les mises à jour techniques, les sauvegardes et la surveillance ne sont jamais décomptées des petites modifications du mois. Nous détaillons ce qu’un contrat doit couvrir dans notre article sur le contrat de maintenance.
Votre site a été créé ailleurs ? Nous commençons par un audit d’entrée à 125 € : hébergement, code, dépendances, sécurité, sauvegardes et bugs déjà présents. Si des corrections sont nécessaires avant de prendre le relais, elles font l’objet d’un devis séparé. Si le site est trop ancien pour être mis à jour proprement, la question devient celle d’une refonte : voir refaire son site ou le mettre à jour.
Pour une application mobile ou un SaaS sur mesure, la même logique s’applique, avec en plus un cadrage de ce qui doit être protégé : qui accède à quoi, où sont hébergées les données. Dès que nous traitons des données personnelles pour votre compte, un accord de traitement des données (DPA) est joint au devis et signé séparément. Pour les automatisations entre vos outils, l’hébergement des données est convenu au devis selon leur sensibilité.
Aucune check-list ne garantit une protection absolue, et notre Digital Audit ne couvre pas la sécurité en profondeur. Pour un contrôle poussé, notre audit de sécurité à 999 € porte uniquement sur ce sujet. Ce travail écarte les erreurs courantes et garde le site à jour : c’est déjà ce qui fait la différence face à des attaques automatisées.
Que faire cette semaine ?
- Repérez qui héberge votre site et quelle version de PHP il utilise.
- Demandez à votre hébergeur ou à votre prestataire si le correctif est appliqué, et si les services ont bien été redémarrés ensuite.
- Si votre version ne peut pas être mise à jour tout de suite, les autorités conseillent de la couper d’Internet en attendant. Un pare-feu applicatif peut aider, mais ne protège que partiellement. Planifiez ensuite la migration.
- Vérifiez que vos sauvegardes existent hors du serveur et qu’elles se restaurent.
- Activez la double authentification sur les accès d’administration, et supprimez les extensions et les comptes qui ne servent plus.
Si vous ne savez pas par où commencer, réservez un appel de 20 min : le pré-audit est gratuit, c’est un premier regard à l’oral. Nous voyons ensemble par quoi commencer.
