Faille de sécurité PHP : votre site WordPress est-il touché ?

Depuis deux jours, « PHP » fait la une. Aux Pays-Bas, DigiD, l'identifiant des citoyens pour les services publics, a été coupé. En Finlande, certains sites gouvernementaux ont été mis hors ligne par précaution. Aux États-Unis, le FBI et la NSA ont demandé aux organisations de couper leurs serveurs si elles ne pouvaient pas appliquer le correctif. En Turquie, la Direction de la cybersécurité de la Présidence a lancé une analyse à l'échelle nationale.

Dans cet article, nous expliquons ce qui s'est passé sans vous noyer sous les détails techniques. Puis nous voyons, étape par étape, comment un organisateur de visites peut savoir si son site est concerné, quoi faire aujourd'hui et comment être mieux préparé la prochaine fois.

D'abord, les bases : qu'est-ce que PHP ?

PHP est un langage de programmation qui tourne en coulisses de nombreux sites web. Quand un visiteur ouvre votre site, le code qui construit la page, transforme votre formulaire de contact en e-mail ou enregistre une réservation dans la base de données est très souvent écrit en PHP.

Même si vous n'en avez jamais entendu parler, vous l'utilisez probablement quelque part. WordPress, WooCommerce, Joomla, Drupal et de nombreux plugins de réservation fonctionnent avec PHP. Selon le FBI, environ 70 % des sites web dans le monde utilisent PHP.

Que s'est-il passé ?

Les 20 et 21 octobre 2026, l'équipe PHP a publié des mises à jour d'urgence pour deux failles de sécurité critiques. Elles portent les identifiants CVE-2026-109618 et CVE-2026-109619 et sont connues ensemble sous le nom de « PHP2Shell ». Toutes deux ont obtenu une note de gravité de 9,2 sur 10.

Pourquoi c'est grave : dans certaines conditions, ces failles permettent à un attaquant d'exécuter le code de son choix sur votre serveur, via internet, sans nom d'utilisateur ni mot de passe. En sécurité, on parle d'exécution de code à distance (RCE). Dit simplement : quelqu'un peut passer votre porte sans avoir besoin de la clé.

Selon Qualys, l'une des failles survient quand des données restent à moitié initialisées parce que le serveur manque de mémoire, l'autre quand, après une erreur, la requête du visiteur suivant relit une mémoire déjà libérée. Des chercheurs ont aussi montré que des données comme des mots de passe, des informations de session et des clés API pouvaient fuiter de la mémoire du serveur.

L'agence Anadolu rapporte que les failles ont été découvertes en août par une société de sécurité nommée Calif, avec l'aide de l'IA. Les correctifs ont été préparés discrètement pendant environ deux mois, mais l'information a fuité dans la presse la veille de leur publication.

Pourquoi est-ce si important ?

• L'ampleur est énorme : Palo Alto Networks a recensé plus de 22,6 millions de systèmes exposés sur internet potentiellement vulnérables.
• Les anciennes versions sont partout : selon Qualys, 71 % des installations PHP dont la version est connue utilisent des versions qui ne sont plus maintenues et ne reçoivent plus de correctifs réguliers.
• Les attaques ont commencé : Cloudflare a signalé du trafic d'attaque visant ces failles, et du code permettant de les exploiter circule déjà.
• Les mises à jour sont lentes : dans les 12 premières heures, seules environ 199 000 des 167 millions d'installations suivies par Qualys avaient été mises à jour.

C'est pourquoi des gouvernements ont coupé des sites. Tant qu'un système n'est pas corrigé, le plus sûr est de fermer la porte par laquelle un attaquant pourrait entrer. En Turquie, la Direction de la cybersécurité a envoyé des alertes urgentes aux institutions publiques et appelé les entreprises privées à vérifier leurs systèmes PHP. Elle a indiqué qu'aucun problème affectant les services n'avait été détecté sur e-Devlet, le portail national de l'administration.

Qu'est-ce que cela peut signifier pour un organisateur de visites ?

Ce qu'un attaquant peut faire une fois entré dépend de ce que votre site contient. Les scénarios les plus probables :

• Fuite de données clients : noms, téléphones, e-mails et données de passeport issus des formulaires de réservation. Selon votre situation et celle de vos clients, des règles comme le RGPD peuvent vous obliger à le déclarer.
• Vol de mots de passe et de clés : le mot de passe de votre base de données et les clés API de votre prestataire de paiement, de votre channel manager ou de votre service d'e-mail.
• Contenu malveillant sur votre site : pages de spam cachées ou code qui redirige les visiteurs ailleurs. Si Google s'en aperçoit, votre site peut s'afficher avec un avertissement et des mois de travail SEO peuvent en pâtir.
• Votre serveur détourné : minage de cryptomonnaies, envoi de spam ou attaques contre d'autres sites.
• Perte de ventes : si vous devez couper le site par précaution, vous ne pouvez plus prendre de réservations, même en pleine saison.

Votre site est-il concerné ? Vérifiez d'abord la version

La première étape est de savoir si votre site tourne sous PHP et avec quelle version. Sous WordPress, allez dans Outils → Santé du site → Infos → Serveur dans l'administration. Votre panneau d'hébergement (cPanel, Plesk, etc.) l'affiche généralement aussi sous « Version de PHP ».

Voici les versions qui corrigent les failles :

• Avec PHP 8.5 : 8.5.12 ou plus récente
• Avec PHP 8.4 : 8.4.27 ou plus récente
• Avec PHP 8.3 : 8.3.36 ou plus récente
• Avec PHP 8.2 : 8.2.35 ou plus récente
• Avec PHP 8.1 ou plus ancien : pas de mise à jour officielle habituelle. Sauf si votre hébergeur a appliqué un correctif spécial, vous devez passer à une version plus récente.

Une remarque : certaines distributions Linux livrent le correctif en conservant l'ancien numéro de version. Un numéro plus bas ne signifie donc pas toujours que votre site est vulnérable. Le plus fiable reste de demander directement à votre hébergeur.

Ce qu'il faut faire aujourd'hui

• Écrivez à votre hébergeur et demandez : « Le PHP de mon serveur a-t-il été mis à jour contre PHP2Shell (CVE-2026-109618 et CVE-2026-109619) ? » La réponse « Nous avons ajouté une règle de pare-feu » ne suffit pas à elle seule. Faites confirmer que PHP lui-même a été mis à jour.
• Sachez qu'une mise à jour de WordPress ne règle pas le problème : la faille n'est pas dans WordPress mais dans le PHP qui tourne en dessous. Les mises à jour de plugins ou de thèmes, les plugins de sécurité et le mode maintenance ne vous protègent pas, car l'attaque peut s'exécuter avant même le chargement de WordPress.
• Si vous gérez votre propre serveur (VPS) : mettez à jour les paquets PHP, puis redémarrez PHP-FPM ou Apache. Un serveur non redémarré continue d'exécuter l'ancien code vulnérable. Sous Docker, récupérez la nouvelle image et recréez vos conteneurs.
• Si vous êtes sur une ancienne version : faites une sauvegarde complète stockée hors du serveur, puis passez à PHP 8.3 ou 8.4. Testez ensuite un par un la page d'accueil, les pages de visites, le formulaire de contact et les étapes de réservation.
• Si vous ne pouvez pas corriger tout de suite : placer le site derrière un pare-feu comme Cloudflare offre une protection temporaire. Si vous avez une équipe technique, elle peut appliquer les réglages provisoires recommandés par PHP (par exemple session.upload_progress.enabled=0). Ce n'est pas une solution complète, cela fait seulement gagner du temps.

Quelqu'un est-il déjà entré ? Les signes à vérifier

Une fois le correctif appliqué, vérifiez si quelqu'un est entré avant que la faille soit fermée :

• Y a-t-il dans WordPress des comptes administrateur que vous ne reconnaissez pas ?
• Un plugin que vous n'avez pas installé apparaît-il ?
• Y a-t-il des fichiers .php dans wp-content/uploads, le dossier de vos images ? Il ne devrait y avoir aucun fichier PHP à cet endroit.
• En cherchant site:votredomaine.fr sur Google, voyez-vous des pages que vous n'avez jamais écrites ?
• Y a-t-il un avertissement dans « Problèmes de sécurité » de Google Search Console ?
• Votre hébergeur vous a-t-il envoyé des alertes de malware, de spam ou d'utilisation inhabituelle des ressources ?

Si vous remarquez l'un de ces signes, demandez à votre hébergeur d'analyser le serveur et de restaurer une sauvegarde saine datant d'avant l'activité suspecte. Changez ensuite tous les mots de passe et clés API : WordPress, hébergement, base de données, e-mail et intégrations de paiement ou de canaux. Si des données clients ont pu fuiter, consultez un conseiller juridique sur vos obligations.

Pour la suite : des précautions durables

PHP2Shell ne sera pas la dernière faille. La vraie question est de savoir à quel point vous serez prêt la prochaine fois. Les habitudes que nous recommandons :

• Restez sur une version maintenue : un logiciel qui n'est plus maintenu ne reçoit plus de correctifs. Aujourd'hui, PHP 8.3 ou 8.4 est un bon choix.
• Confiez les mises à jour à quelqu'un : qui met votre site à jour, et à quelle fréquence ? La réponse doit être claire. Un hébergement infogéré ou un contrat de maintenance permet de le formaliser simplement.
• Sachez ce que vous avez : site principal, anciennes pages de campagne, installations de test, sous-domaines oubliés… Tenez une liste avec le serveur et la version de chacun. Les attaquants adorent les sites oubliés.
• Supprimez ce dont vous n'avez pas besoin : effacez les plugins, thèmes et anciens sites inutilisés. Chaque élément en plus est une porte de plus qu'une faille peut ouvrir.
• Placez votre site derrière un pare-feu : un service comme Cloudflare devient votre première ligne de défense quand une nouvelle faille est annoncée, en attendant le correctif.
• Séparez mots de passe et clés : n'écrivez pas les clés API dans le code, donnez à chaque service uniquement les accès nécessaires et changez les clés régulièrement.
• Gardez les sauvegardes hors du serveur et testez leur restauration : une sauvegarde jamais restaurée est une sauvegarde dont vous ne savez pas si elle fonctionnera.
• Surveillez votre site : la surveillance de disponibilité, les alertes Search Console et les alertes de modification de fichiers vous montrent un problème avant vos clients.
• Rédigez un court plan d'incident : décidez à l'avance qui appeler, comment mettre le site hors ligne temporairement et comment informer vos clients en cas de problème.

Vue d'ensemble : les failles sont découvertes plus vite

Le plus marquant dans cette histoire, c'est que les failles ont été trouvées avec l'aide de l'IA. Les mêmes outils sont à la portée de personnes mal intentionnées. Désormais, les failles seront trouvées plus vite, et exploitées plus vite aussi.

L'époque du « on mettra à jour quand on aura le temps » est donc révolue. Pour un organisateur de visites, le site n'est plus seulement une vitrine. C'est un outil commercial qui prend des réservations et stocke des données clients : le sécuriser fait partie de la continuité de votre activité.

Chez Monotim, nous construisons des sites sur une base moderne qui n'est pas directement touchée par ce type de faille dans un langage serveur. Mais aucune technologie ne reste sûre pour toujours. Ce qui fait vraiment la différence, c'est de surveiller le site et de pouvoir agir vite en cas de problème.

Si vous n'êtes pas sûr que votre site soit concerné par PHP2Shell, ou si votre hébergeur ne vous a pas donné de réponse claire, nous pouvons le regarder ensemble.