Après une faille PHP, le site web d’un particulier est-il sûr ? Comment vérifier WordPress, un blog ou un site e-commerce ?

Une faille PHP ne signifie pas automatiquement qu’un site a été piraté : le risque dépend de la version exécutée, des conditions d’exploitation et des correctifs installés. Ce guide explique comment vérifier l’environnement, les composants WordPress, les journaux et les comptes, puis comment prioriser les actions pour un blog ou un site e-commerce.

Le calendrier officiel de PHP prévoit deux années de support actif, puis deux années de correctifs de sécurité pour une branche prise en charge ; au-delà, elle arrive en fin de support (politique officielle de prise en charge de PHP et liste des branches en fin de support). Une faille PHP ne signifie donc pas que tous les sites sont compromis : vérifiez d’abord la version réellement exécutée, les conditions de la faille et l’état du correctif, puis examinez l’application, les journaux et les comptes.

Verdict — Une alerte justifie une vérification ; elle ne constitue pas une preuve d’intrusion. Tant que la version et les conditions d’exploitation ne sont pas confirmées, ne concluez ni que le site est touché ni qu’il est sûr.

Cet article s’adresse aux personnes qui administrent un site WordPress ou un blog et veulent contrôler leur environnement sans confondre PHP avec le logiciel du site. Il concerne aussi les responsables de sites e-commerce qui doivent vérifier les commandes, les accès et les données clients.

Ce qu’une faille PHP permet réellement de conclure

PHP est un composant de l’environnement serveur. WordPress, son thème et ses extensions sont des composants distincts qui s’exécutent dans cet environnement. Une alerte visant une version ou une fonction de PHP ne prouve pas, à elle seule, que votre site utilise la version concernée. Elle ne prouve pas non plus qu’un tiers a exploité la faille.

Nous commençons donc par séparer deux questions :

• Le site est-il exposé ? Il faut établir que le serveur exécute une version concernée, que les conditions décrites dans l’avis sont réunies et qu’aucun correctif ne neutralise le risque.
• Existe-t-il des indices d’intrusion ? Il faut examiner des éléments propres au site : connexions, comptes, fichiers, requêtes ou changements de contenu. Une exposition potentielle n’est pas un indicateur d’intrusion en soi.

Une version PHP non prise en charge mérite également une attention particulière, même si aucun incident n’est visible. L’avis officiel et les informations de prise en charge permettent de déterminer si la branche reçoit encore des correctifs. Ne déduisez pas la version à partir de l’apparence du site, de son adresse ou de la date d’installation de WordPress.

Vérifier l’environnement avant de modifier le site

Relevez la version utilisée par le site auprès du panneau d’hébergement, de l’interface de gestion ou de l’assistance technique. Selon la configuration, plusieurs sites d’un même compte peuvent utiliser des versions différentes. Une version affichée dans un outil de développement, sur votre ordinateur ou dans une documentation ne confirme pas celle qui exécute le site en production.

Demandez à l’hébergeur de confirmer les éléments suivants :

• la version de PHP effectivement utilisée par le site concerné ;
• la branche de prise en charge et son statut ;
• l’existence d’un correctif ou d’une mesure d’atténuation appliquée côté serveur ;
• la date ou la fenêtre de déploiement prévue, si une mise à jour est nécessaire ;
• les journaux disponibles et la période qu’ils couvrent.

L’hébergeur est la source la mieux placée pour confirmer la configuration serveur qu’il contrôle. De votre côté, relevez aussi la version de WordPress, du thème et de chaque extension. Ce sont des informations différentes : actualiser WordPress ne met pas nécessairement à niveau PHP, et changer la version de PHP ne met pas à jour les extensions.

Si l’hébergeur ne peut pas confirmer la version ou l’état du correctif, ne devinez pas et ne tentez pas une modification de serveur à l’aveugle. Demandez une réponse écrite et conservez-la avec la date de votre contrôle. Le changement de version peut affecter la compatibilité du site ; il doit être planifié selon les instructions de l’hébergeur et testé dans la mesure du possible.

Contrôles adaptés à WordPress, aux blogs et aux boutiques

Pour WordPress, examinez séparément le cœur, les extensions et le thème. Notez les versions installées, les mises à jour proposées et les composants qui ne sont plus maintenus. Les instructions officielles de WordPress pour gérer les extensions décrivent les opérations disponibles dans l’administration. Le guide officiel de durcissement de WordPress complète ces contrôles par des recommandations de sécurité générales.

Pour un blog, ajoutez un examen des comptes et des contenus. Vérifiez si des comptes administrateurs sont inconnus, si des articles ou des pages ont été modifiés sans intervention prévue, et si des fichiers du site ont changé de façon inattendue. Une publication programmée, une mise à jour automatique ou une action d’un autre membre de l’équipe peut expliquer certains changements : comparez les heures et les comptes avant de les qualifier de suspects.

Pour un site e-commerce, donnez la priorité aux fonctions qui touchent les commandes, les paiements, les rôles d’administration et l’accès aux données clients. Recherchez les changements inattendus dans la configuration des paiements ou des comptes, et demandez aux personnes concernées si elles reconnaissent les opérations observées. Un journal de commande qui semble anormal ne prouve pas, à lui seul, que les données de paiement ou les informations clients ont été consultées.

Ce tableau sert à organiser l’enquête, pas à attribuer automatiquement un niveau de risque à un site. Les enregistrements propres à votre hébergement et à votre application priment sur une supposition fondée uniquement sur le type de site.

Examiner les journaux, les fichiers et les comptes

Les journaux peuvent aider à reconstruire ce qui s’est passé : connexions, changements de configuration, requêtes reçues et actions d’administration. Leur valeur dépend de leur contenu, de leur horodatage et de leur conservation. Les recommandations de l’OWASP sur la journalisation de sécurité insistent sur la nécessité de produire des journaux utiles à l’analyse, et pas seulement d’accumuler des événements difficiles à interpréter.

Procédez dans cet ordre :

1. Préservez ce qui existe. Téléchargez ou demandez une copie des journaux accessibles et notez la période couverte. Conservez les originaux sans les modifier.
2. Relevez les événements inhabituels. Cherchez les connexions que vous ne reconnaissez pas, les créations ou modifications de comptes et les changements de configuration survenus à une heure inattendue.
3. Comparez les fichiers. Si l’hébergement ou votre processus de déploiement conserve un historique, comparez les dates et les versions des fichiers concernés. Une date récente seule ne démontre pas une activité malveillante.
4. Contrôlez les contenus. Vérifiez les pages, articles, redirections et éléments visibles du site. Pour une boutique, comparez les changements observés avec l’historique des commandes et des opérations autorisées.
5. Rattachez chaque constat à une source. Notez l’heure, le compte, le fichier ou l’événement concerné et l’explication connue. Signalez ce qui reste incertain au lieu de présenter une hypothèse comme un fait.

Un accès inconnu peut provenir d’un membre de l’équipe, d’un outil d’automatisation ou d’une adresse réseau partagée. Un fichier modifié peut correspondre à une mise à jour légitime. L’accumulation d’indices concordants demande davantage d’attention qu’un événement isolé, mais l’interprétation doit tenir compte du fonctionnement réel du site.

À éviter — Ne supprimez pas un fichier suspect et ne restaurez pas une sauvegarde avant d’avoir conservé les éléments nécessaires à l’analyse. Ces actions peuvent effacer des indices ou remplacer des données utiles pour comprendre l’incident.

En cas d’anomalie, limiter le risque avant de restaurer

Si vous observez plusieurs signes concordants ou une activité qui menace les commandes ou les comptes, contactez rapidement l’hébergeur ou une personne compétente en sécurité. Décrivez ce que vous avez constaté, indiquez les horaires et transmettez une copie des journaux lorsque cela peut être fait sans altérer les originaux. Les recommandations de gestion d’incident du NIST, dans sa publication SP 800-61 révision 3, organisent la réponse autour de quatre fonctions : préparation, détection, réponse et rétablissement. Ce cadre rappelle que le rétablissement vient après l’identification et la maîtrise du problème, pas à la place de celles-ci.

En pratique, la réponse doit rester proportionnée aux indices :

• Limiter l’activité à risque. Avec l’aide de l’hébergeur, bloquez les accès suspects ou restreignez temporairement les fonctions concernées. Pour une boutique, préservez autant que possible la continuité des opérations légitimes.
• Conserver les éléments utiles. Gardez les journaux, les messages de l’hébergeur, les alertes et une trace des changements déjà effectués.
• Réparer depuis une source fiable. Appliquez les correctifs disponibles pour PHP et les composants concernés. Si une restauration est nécessaire, utilisez une sauvegarde dont l’intégrité et la date ont été vérifiées.
• Renouveler les secrets pertinents. Une fois les accès maîtrisés, changez les mots de passe et clés susceptibles d’avoir été exposés, en tenant compte des recommandations de l’hébergeur et des outils utilisés.
• Vérifier le retour au fonctionnement normal. Contrôlez les comptes, le contenu et les fonctions touchées. Ne promettez pas qu’une restauration a éliminé tout risque avant d’avoir vérifié le résultat.

Pour un site e-commerce, si les éléments recueillis laissent penser que des données clients ou des opérations de paiement ont pu être concernées, demandez conseil sur les obligations de notification applicables à votre situation. Celles-ci dépendent du contexte et des règles pertinentes : ne déduisez pas d’une alerte PHP, seule, qu’une notification est obligatoire ou inutile.

Procéder à une vérification complète sans tirer de conclusion hâtive

La revue peut être consignée dans une fiche simple. Indiquez le domaine examiné, la date du contrôle, la version PHP confirmée, l’avis officiel consulté, les mises à jour relevées, les journaux disponibles et la personne qui a validé chaque résultat. Cette trace permet de distinguer les faits confirmés des questions encore ouvertes.

Cochez les contrôles au fur et à mesure :

• [ ] L’avis officiel correspondant à la faille a été retrouvé ; ses versions concernées et conditions ont été comparées à la configuration du site.
• [ ] La version PHP réellement exécutée a été confirmée par le panneau ou l’hébergeur.
• [ ] Le statut de prise en charge et l’existence d’un correctif ont été vérifiés.
• [ ] Les versions du cœur WordPress, des extensions et du thème ont été examinées séparément.
• [ ] Les comptes, les connexions, les fichiers et les contenus ont été contrôlés à partir des traces disponibles.
• [ ] Les sauvegardes et la procédure de restauration ont été vérifiées sans écraser les éléments d’analyse.
• [ ] Pour une boutique, les accès aux commandes, aux paiements et aux données clients ont été examinés.
• [ ] Les anomalies et les points non confirmés ont été signalés à l’hébergeur ou à une personne compétente.

Pour un site de développement ou de préproduction, séparez ces environnements du site public et utilisez des comptes distincts lorsque l’organisation le permet. Une machine de travail distante ne corrige pas une version PHP vulnérable sur le serveur de production. Si vos tests doivent aussi se dérouler dans un environnement macOS temporaire, un environnement Mac à distance peut servir à cette tâche de développement, mais il ne remplace ni le contrôle de l’hébergement web ni l’intervention de son équipe d’exploitation. Pour comprendre le contexte de cette offre, consultez également la présentation de ZekVPS.

Questions fréquentes sur les vérifications après une faille PHP

Comment vérifier si une faille PHP concerne mon site WordPress ?

Relevez d’abord la version de PHP réellement utilisée par l’hébergement, puis comparez-la aux versions et conditions indiquées dans l’avis officiel correspondant à la faille. Vérifiez séparément le cœur WordPress, les extensions et le thème : leur mise à jour ne confirme pas celle de PHP. Si le panneau d’hébergement ne précise pas la version exécutée, demandez confirmation à l’hébergeur.

Quelles vérifications faire en premier sur un blog après une alerte PHP ?

Confirmez l’environnement et le statut du correctif, puis examinez les comptes administrateurs, les connexions récentes, les articles ou pages modifiés sans autorisation et les fichiers récemment changés. Un élément isolé peut avoir une explication légitime. Conservez les journaux et les dates observées avant toute suppression, restauration ou mise à jour susceptible d’effacer des indices.

Comment savoir si un site e-commerce a été compromis ?

Une alerte PHP ne suffit pas à établir une intrusion. Vérifiez les accès administrateurs, les changements de configuration, les journaux et les actions inhabituelles dans les commandes ou les flux de paiement. Contrôlez également si des données de clients ont pu être consultées. En cas de doute, limitez les accès concernés, préservez les preuves et demandez conseil à l’hébergeur ou à un spécialiste.

Comment savoir si la version de PHP de mon hébergement doit être corrigée ?

Comparez la version réellement exécutée avec l’avis de sécurité officiel et le calendrier de prise en charge de PHP. Une branche arrivée en fin de support ne reçoit plus les mêmes garanties qu’une branche maintenue. Vérifiez aussi que l’application fonctionne avec la version cible avant un changement. L’hébergeur peut confirmer la version active et la procédure de mise à niveau.

Le contrôle le plus sûr reste celui qui s’appuie sur une version confirmée, un avis officiel et des traces conservées. Si l’environnement est impossible à vérifier ou si des indices d’intrusion concordants apparaissent, faites intervenir l’hébergeur ou un spécialiste avant de modifier les fichiers. La location d’un Mac peut faciliter des tests temporaires de développement ou de compatibilité, contrairement à un poste local déjà mobilisé ; elle ne résout toutefois pas les limites de journaux, de permissions ou de correctifs du serveur. Consignez les vérifications effectuées et les points qui restent à confirmer.