Call'ade Mobile, Cybersécurité
Audit cybersécurité d'un site WordPress piraté
Comment j'ai établi, sans rien forcer, que le site d'une boutique de réparation hébergeait du spam actif, et ce que j'ai proposé pour en sortir.
Méthode
Regarder sans toucher
Je n'avais aucun mandat sur ce site. Tout ce qui suit vient de ce qu'il montre déjà à n'importe quel visiteur, relevé le 5 octobre 2026 entre 7 h 02 et 7 h 20 (heure UTC).
Un audit de sécurité commence souvent par un scanner. Ici, c'était exclu : je n'étais ni le propriétaire du site, ni son prestataire. Envoyer des requêtes d'attaque ou essayer un mot de passe sur le site d'un tiers, c'est déjà une tentative d'accès frauduleux au sens de l'article 323-1 du Code pénal, même avec de bonnes intentions.
J'ai donc travaillé comme un visiteur attentif. J'ai lu le code HTML des pages, les en-têtes que le serveur renvoie avec chaque réponse, le sitemap que le site publie pour Google, et l'API REST de WordPress, qui répond en lecture à tout le monde tant que personne ne la ferme. J'ai parcouru les 132 adresses liées depuis le site, au rythme d'une requête par seconde, pour ne rien charger côté serveur.
Cette contrainte n'a presque rien coûté. Un site compromis pour du référencement frauduleux a besoin d'être vu : le spam n'a de valeur que si Google le lit. Il se trouve donc, par construction, dans les pages publiques.
Ce que j'ai lu
- Les pages publiques et leur code HTML
- Les en-têtes de réponse d'une requête ordinaire
- Le sitemap et ses neuf sous-sitemaps
- L'API REST publique, en lecture seule
- Les rapports Lighthouse
- Le statut Google Safe Browsing
Ce que je n'ai pas fait
- Aucun scan de vulnérabilité
- Aucune tentative de connexion
- Aucune requête vers l'administration ou les dossiers des extensions
- Aucun formulaire envoyé
- Aucun test de la faille citée plus bas
Constats
Quatre signes, tous visibles depuis la rue
Pris un par un, chacun a une explication innocente possible. Ensemble, ils décrivent un site dont quelqu'un d'autre se sert.
32 articles de casino, antidatés
L'API publique annonçait 38 articles. Aucun n'avait été écrit par le magasin : 6 venaient du thème de démonstration, 32 parlaient de casino et de paris sportifs, en vietnamien et en anglais, chacun avec un lien vers un site de jeu. Ils s'affichaient sous l'en-tête de Call'ade, avec son numéro de téléphone juste au-dessus.
Leurs dates allaient de janvier 2020 à octobre 2024. Elles étaient fausses, et le site le dit lui-même. La preuve tient en quatre recoupements, résumés dans le tableau : l'ordre de création des articles contredit leur date, et leur propre texte parle d'années qui n'existaient pas encore.
Pourquoi antidater ? Un article publié aujourd'hui apparaît en tête de la liste dans l'administration, là où le gérant le verrait. Daté de 2020, il se range tout en bas, sous des pages que personne ne rouvre. La date réelle d'injection ne se voit pas de l'extérieur, et je ne l'affirme pas.
| Recoupement | Ce que montrent les données publiques |
|---|---|
| L'ordre des numéros | WordPress numérote les articles dans l'ordre de leur création. Les articles de démonstration du thème, datés du 11 novembre 2023, portent les numéros 344 à 349. Sept articles de casino datés de janvier à avril 2020 portent des numéros supérieurs à 3 000 : ils ont donc été créés après novembre 2023. |
| L'année dans l'adresse | Ces sept articles « de 2020 » ont tous une adresse qui se termine par -2025. |
| Le texte lui-même | Un article daté du 21 avril 2024 parle de l'année 2026 dans son titre, et cite « 2026 » 33 fois dans son texte. |
| Aucune relecture | Sur les 38 articles, la date de modification est identique à la date de publication. |
Environ 16 000 commentaires de spam, et ça continue
Sous un article de démonstration du thème, la page pesait 24,5 Mo de HTML. Elle portait 15 533 commentaires marqués « en attente de modération » et des liens vers 9 147 domaines différents : marchés du darknet, cryptomonnaies, casinos.
« En attente de modération » devrait vouloir dire invisible. Le module de commentaires du thème les affichait pourtant à tous les visiteurs. L'API, elle, ne comptait que 12 commentaires approuvés : l'outil que regarde le gérant ne montrait rien d'anormal.
Le rythme dit le reste. Ce n'est pas une vieille attaque oubliée : 5 722 commentaires en septembre 2026, 1 162 sur les quatre premiers jours d'octobre, le dernier daté du 4 octobre.
- Juin 20261 058
- Juillet 20264 732
- Août 20262 793
- Septembre 20265 722
- Du 1er au 4 octobre1 162
Un bloc de liens caché sur l'accueil
Le code de l'accueil contenait un bloc « Actualités » masqué sur les quatre tailles d'écran. Le visiteur ne le voit jamais. Google, qui lit le code, y trouvait trois liens vers les derniers articles de casino, avec leurs titres en balise de sous-titre. C'est du texte caché au sens des règles anti-spam de Google, et il est placé sur la page la plus forte du site, celle qui transmet le plus d'autorité.
Ce même bloc avait un effet secondaire : il créait une pagination. Les adresses /page/2/ à /page/14/ répondaient toutes avec une copie de l'accueil. J'y reviens dans la page consacrée au SEO.
Les comptes du site, listés en public
L'API des utilisateurs répondait à tout le monde. Elle donnait le compte principal, dont le nom affiché était une adresse e-mail, et un second compte à l'intitulé générique, auteur des 25 articles de casino les plus récents. L'auteur des 7 autres n'existait plus : son compte avait été supprimé, ses articles non. Je ne reproduis ici ni les noms, ni les identifiants, ni l'adresse : savoir qu'ils étaient publics suffit à décider qu'il faut tout changer.
Exposition
Une surface d'attaque bien plus grande que le besoin
Un site vitrine de trois boutiques n'a besoin que de pages et d'un formulaire. Celui-ci faisait tourner une boutique en ligne, une dizaine d'extensions et des formulaires de démonstration.
Les en-têtes de sécurité absents
Chaque réponse d'un serveur web porte des en-têtes, invisibles à l'écran, qui disent au navigateur comment se protéger. Le minimum courant tient en quelques lignes de configuration. Ici, la redirection vers HTTPS était correcte, et presque tout le reste manquait.
| En-tête | État | Ce que ça laisse faire |
|---|---|---|
| Redirection de HTTP vers HTTPS | Présente (301) | Correct |
| Strict-Transport-Security (HSTS) | Absent | Le navigateur ne retient pas que le site exige HTTPS |
| X-Frame-Options | Absent | Le site peut être affiché dans le cadre d'une page tierce |
| Content-Security-Policy | Minimale | Aucune restriction sur les sources de scripts |
| X-Content-Type-Options, Referrer-Policy, Permissions-Policy | Absents | Protections de base non activées |
| Versions des logiciels | Affichées | PHP, WordPress, WooCommerce, Elementor lisibles dans le code de la page |
Des versions en retard, et une faille publique
Le code de l'accueil affichait les versions de WordPress et de ses principales extensions. La plupart des petites extensions étaient à jour, signe de mises à jour automatiques actives. Les trois briques les plus lourdes, elles, ne suivaient pas.
Je ne cite qu'une faille dont une page publique vise explicitement la version installée : CVE-2026-48888, un déni de service sans authentification sur WooCommerce avant 11.1.0, publiée le 7 septembre 2026 et corrigée en 11.1.0 (fiche WPScan). Je ne l'ai pas testée. Elle ne dit rien du point d'entrée de l'intrusion, qui ne se voit pas de l'extérieur. Elle dit autre chose : WooCommerce tournait pour une boutique en ligne qui n'existait pas.
| Logiciel | Version affichée | Dernière version | Remarque |
|---|---|---|---|
| WordPress | 6.9.9 | 7.1.2 | Branche encore maintenue |
| Elementor | 4.1.4 | 4.3.3 | Aucune faille publique sur cette version |
| WooCommerce | 10.7.0 | 11.1.2 | CVE-2026-48888, corrigée en 11.1.0 |
| All in One SEO | 5.0.2.1 | 5.0.2.1 | À jour |
Google ne signalait encore rien
Le rapport de transparence Safe Browsing de Google ne levait aucun drapeau sur le domaine, avec une dernière analyse datée du 4 août 2026. Les navigateurs n'affichaient donc pas d'écran rouge. C'est une bonne nouvelle à moitié : Safe Browsing cherche les logiciels malveillants et l'hameçonnage, pas le spam de référencement. Un site peut être déclassé dans la recherche bien avant qu'un navigateur ne le bloque.
Impact
Ce que ça coûte à une boutique
Le site ne vend rien en ligne et ne stocke pas de carte bancaire. On pourrait croire qu'il n'y a rien à perdre. Il y a le nom du magasin.
La confiance
Un client qui cherche « Call'ade » et tombe sur une page de paris en vietnamien, sous le logo et le numéro du magasin, ne se dit pas que le site a été piraté. Il se dit que l'endroit est louche. La boutique a 867 avis à 4,9 sur 5 sur sa fiche Google de Villefranche : c'est cette réputation que le spam utilise comme vitrine.
Les règles anti-spam de Google visent précisément ce cas : contenu injecté par un tiers, liens cachés, pages créées pour manipuler le classement. Le site risque une action manuelle, ou plus simplement un déclassement, sur les recherches qui comptent pour lui : « réparation téléphone Villefranche-sur-Saône » et son propre nom. Et le site aggravait son cas lui-même, en déclarant les 32 articles de casino dans son sitemap.
Les clients
Les liens de spam renvoient vers des marchés du darknet et des sites de jeu, publiés sous un domaine que les clients du magasin ont des raisons de croire sûr. Personne n'a été victime à ma connaissance. Le risque, lui, est en ligne tant que les pages le sont.
Plan de nettoyage
Six étapes, dans cet ordre
L'ordre compte. Nettoyer avant de changer les accès, c'est laisser la porte ouverte à celui qui a déjà la clé.
Changer tous les accès, le même jour
Hébergement, base de données, comptes du site, messagerie, registrar du domaine. Supprimer les comptes de publication que personne ne reconnaît. Activer la double authentification partout où elle existe. Tant qu'un seul mot de passe ancien survit, le nettoyage peut être défait dans la nuit.
Garder une copie hors ligne, pour preuve
Une sauvegarde complète du site et de la base, rangée hors du serveur et jamais remise en ligne. Elle sert à dater l'intrusion plus tard, ou à répondre à un assureur.
Mettre à jour, ou mieux, retirer
WordPress, Elementor et WooCommerce avaient du retard. Mais la vraie mise à jour, c'est la suppression : WooCommerce et trois packs d'extensions tournaient pour une boutique en ligne qui n'existait pas.
Nettoyer le contenu
Supprimer les 32 articles de casino, fermer les commentaires, retirer le bloc de liens caché de l'accueil, vider les comptes inconnus. Vérifier aussi les fichiers du thème et des extensions, là où une porte dérobée se cache d'habitude.
Faire sortir le spam de Google
Chaque ancienne adresse de spam répond « supprimé » (code 410), un sitemap neuf ne déclare que les vraies pages, l'outil de suppression de la Search Console accélère pour les plus visibles.
Surveiller, puis vérifier
Search Console (actions manuelles, problèmes de sécurité, couverture), alertes de connexion, contrôle des en-têtes. Vérifications à J+1, J+7 et J+30, puis chaque mois.
J'ai aussi recommandé de ne pas migrer WordPress vers le nouveau site. Une base WordPress compromise peut garder une porte dérobée dans un fichier de thème, une option de la base ou un compte discret. La recopier, c'est la déplacer. Le contenu utile du magasin tenait en neuf pages : il est plus sûr de le réécrire que de le transférer.
Refonte
Moins de choses à attaquer
La meilleure protection d'une extension, c'est de ne pas l'installer. La refonte retire tout ce dont la boutique n'a pas besoin.
Le nouveau site est construit en Astro, en sortie statique : les pages sont fabriquées une fois, à la publication, puis servies comme de simples fichiers. Aucun code ne tourne quand un visiteur arrive, il n'y a pas de base de données à interroger depuis la page, pas d'extension à tenir à jour. Une faille de type WooCommerce n'a tout simplement nulle part où exister.
Le gérant garde la main sur ses prix et ses horaires grâce à une administration Payload, une application à part, sur une autre adresse, que le site ne mentionne nulle part. Quand il enregistre un prix, le site se reconstruit. Il n'y a qu'un compte à protéger, et il se protège avec un mot de passe long et une double authentification.
| Site WordPress actuel | Nouveau site | |
|---|---|---|
| Code exécuté à chaque visite | PHP et base de données | Aucun : des fichiers HTML déjà construits |
| Extensions | Une dizaine, dont 4 packs pour Elementor | Aucune |
| Administration | Sur le même domaine que le site | Application séparée, sans lien depuis le site |
| Commentaires | Ouverts, affichés avant modération | Aucun |
| Formulaires | 5, dont un de démonstration | Un seul point d'entrée, avec champ piège et limite de débit |
| Comptes publics | Listés par l'API | Aucune API publique de comptes |
| En-têtes de sécurité | Presque tous absents | HSTS, interdiction des cadres, politique de contenu |
Ce choix a un coût honnête à dire : plus de module de blog en trois clics, plus d'extension à ajouter un soir pour tester une idée. Pour une boutique qui n'a jamais publié un article elle-même, et dont le blog a servi de porte d'entrée au spam, c'est un renoncement facile.
Aller plus loin
L'étude complète et les autres angles
Étude de casToute l'étude Call'ade MobileLe déroulé complet : point de départ, analyse, diagnostic, stratégie, maquette et mesures.Lire
SEOLe SEO local en détailLe sitemap, les titres, l'incohérence des coordonnées, la recherche de mots-clés et le plan de migration en 301 et 410.Lire
DesignLe design en détailLa boutique comme identité, la palette, la typographie, la vague, la barre d'action mobile et l'administration Payload.Lire
Le service
Cybersécurité des TPE et PME
Un site qui se comporte bizarrement, des articles que personne n'a écrits ? Je fais le même relevé sur le vôtre, sans rien casser.