Faille PHP critique : comment j'ai sécurisé mon serveur
Mercredi 21 octobre 2026, PHP a publié hors calendrier, comme annoncé la veille, un correctif pour deux failles critiques, notées 9,2 sur 10. Le soir même, l'infrastructure de Codami était protégée et auditée : aucune trace d'intrusion n'a été identifiée.
Vous n'en avez sans doute pas entendu parler, et c'est normal : c'est justement mon travail que vous n'ayez pas à vous en soucier. Mais je crois à la transparence. Voici donc ce qui s'est passé, ce que j'ai fait, et ce que ça dit de la façon dont un site internet doit être entretenu.
Ce qui s'est passé
Deux failles pouvaient permettre à un inconnu de prendre le contrôle d'un serveur à distance, sans mot de passe. Elles sont classées critiques, la catégorie de gravité la plus élevée.
PHP est le langage qui fait tourner une grande partie du web, dont WordPress. Ses équipes avaient prévu de publier le correctif le mercredi à 16h. Mais selon plusieurs sources spécialisées, des informations ont circulé la veille sur Internet, et des tentatives d'attaque auraient été repérées avant même la sortie du correctif.
Pour les gestionnaires de serveurs, la course était lancée : appliquer la correction avant que les attaques ne se généralisent.
Pourquoi ça vous concerne
Si vous avez un site internet, il y a de bonnes chances qu'il repose sur PHP, même si vous n'avez jamais entendu ce nom. C'est le cas de tous les sites WordPress, de nombreuses boutiques en ligne et de beaucoup d'outils d'administration.
Un serveur compromis, ce n'est pas seulement un site défiguré. C'est un accès possible à vos données clients, à vos commandes, à vos moyens de paiement en ligne.
La vraie question à vous poser n'est donc pas « mon site utilise-t-il PHP ? », mais : « qui s'est occupé de cette faille pour moi, et quand ? » Si vous ne connaissez pas la réponse, c'est peut-être que personne ne l'a fait.
Ce que j'ai fait, étape par étape
Voici comment s'est déroulée l'intervention. Je ne donne volontairement aucun détail technique exploitable : un article public n'a pas à servir de mode d'emploi.
- Préparer avant la sortie : PHP avait annoncé le correctif la veille. Avant sa sortie, j’ai vérifié la version de PHP installée sur mon serveur et annoncé l’intervention prévue en fin d’après-midi.
- Mettre à jour tout de suite : J'ai installé la dernière version disponible pour mon système. Le correctif du jour, lui, n'était pas encore arrivé chez mon fournisseur de paquets : c'est fréquent, il faut parfois attendre quelques heures.
- Appliquer les protections temporaires officielles : Les équipes de PHP ont publié des réglages qui bloquent une partie des attaques en attendant le correctif. Je les ai appliqués, en encadrant ceux qui pouvaient avoir des effets de bord. Ces réglages réduisent le risque, mais seule la mise à jour de PHP corrige la faille.
- Ajouter un contrôle d'accès devant l'interface d'administration : Le temps de l'intervention, chaque personne devrait confirmer son identité par un code envoyé par e-mail avant d'atteindre Hub. Une requête anonyme n'atteignait plus Hub. Cette protection a été levée une fois le correctif installé, et reste prête à être réactivée en quelques minutes.
- Fermer les portes dérobées : J'ai configuré le serveur pour qu'il n'accepte plus que le trafic passant par ce contrôle. Impossible de le contourner en visant directement son adresse. Cette mesure, elle est permanente.
- Vérifier qu'aucune intrusion n'avait eu lieu : J'ai audité le serveur : fichiers récents, processus, connexions, journaux. Résultat : des tentatives automatisées visant d'anciennes failles connues, toutes rejetées, et aucune trace d'intrusion.
- Installer le correctif définitif : Le lendemain matin, le correctif est arrivé chez mon fournisseur et s'est installé automatiquement. Mon serveur est désormais à jour, et les protections temporaires qui n'étaient plus utiles ont été retirées.
Ce que j'en retiens
Une crise révèle ce qui marche, et ce qui doit être amélioré. Voici ce que je retiens de cette intervention.
- Votre site et votre outil de gestion sont liés : Les articles de blog que vous voyez sur le site sont publiés depuis Hub. En renforçant temporairement l'accès à Hub, je savais que leur affichage serait interrompu un moment. J'ai fait le choix de la sécurité d'abord, puis rétabli les articles dans la soirée.
- Toutes les portes d'entrée doivent être fermées : Une protection n'est utile que si personne ne peut passer à côté. J'ai vérifié que tout le trafic web vers le serveur passe désormais par elle.
- Vérifier plutôt que supposer : Une fois le serveur protégé, je l'ai examiné en détail pour m'assurer qu'aucun problème n'était survenu. Tout était en ordre, mais je préfère le savoir que l'espérer.
- Prévenir avant d'intervenir : Chaque intervention est annoncée avant, suivie pendant et confirmée une fois terminée. Une mise à jour de sécurité ne devrait jamais être une surprise.
Ce que ça change pour vous
Un site internet n'est pas un projet qu'on livre puis qu'on oublie : c'est une fondation qu'il faut entretenir. C'est pour ça que l'offre de Codami comporte une troisième étape, la pérennité, à 35 € par mois.
Concrètement, cet abonnement couvre exactement ce que vous venez de lire :
- l'hébergement sécurisé et les mises à jour techniques ;
- les sauvegardes quotidiennes, régulièrement testées par une restauration automatique ;
- la surveillance du serveur ;
- et une intervention rapide quand une faille de sécurité est publiée.
Questions fréquentes
- Mon site WordPress est-il concerné ?
- Très probablement, car WordPress fonctionne avec PHP. Toutes les versions antérieures au correctif du 21 octobre 2026 sont touchées. Demandez à votre hébergeur ou à votre prestataire si la mise à jour a été faite.
- Mon site tourne sur une ancienne version PHP, que faire ?
- PHP 8.1 et les versions plus anciennes ne sont plus maintenues par le projet PHP. Vu la gravité des failles, l'équipe PHP a exceptionnellement publié des correctifs pour ces versions, mais leur installation dépend de votre hébergeur, et les protections temporaires ne protègent que partiellement. La recommandation officielle reste de passer à une version maintenue, PHP 8.2 ou plus récente.
- Je n'ai pas de prestataire, que faire ?
- Contactez votre hébergeur : la plupart appliquent ces correctifs eux-mêmes sur leurs offres mutualisées. Si vous gérez votre propre serveur, la mise à jour est à votre charge.
- Une extension WordPress suffit-elle ?
- Non. Ces failles peuvent se déclencher avant même que WordPress ne démarre. Seule la mise à jour de PHP corrige le problème.
- Mon site a-t-il été piraté ?
- Un site piraté ne se voit pas toujours. En cas de doute, un audit du serveur permet de vérifier l'absence de fichiers suspects ou d'activité anormale.
Sources :
Qui veille sur votre site en ce moment ?
Hébergement sécurisé, mises à jour, sauvegardes testées et une intervention rapide en cas de faille. Pour 35 € par mois.