wp2shell : votre site vitrine WordPress est peut-être déjà une porte d'entrée

Il existe dans presque chaque PME un serveur dont personne ne parle : le site vitrine. Installé il y a trois ou cinq ans par un prestataire, il « marche tout seul », personne ne s'y connecte plus, et il ne figure dans aucun inventaire. Depuis la mi-juillet, ce site oublié est très exactement la cible d'une campagne d'attaques en cours : wp2shell, un enchaînement de deux failles critiques du cœur de WordPress qui permet de prendre le contrôle d'un site sans compte, sans mot de passe et sans le moindre plugin vulnérable.

Ce qui s'est passé : deux failles, un enchaînement redoutable

Le 17 juillet 2026, les chercheurs de Searchlight Cyber ont publié le détail de deux vulnérabilités du cœur de WordPress, référencées CVE-2026-63030 et CVE-2026-60137. La première est une faille logique dans le traitement des requêtes groupées de l'API REST, la seconde une injection SQL dans un paramètre de recherche d'articles. Prises isolément, elles sont déjà sérieuses. Chaînées l'une à l'autre, elles forment ce que les chercheurs ont baptisé wp2shell : une exécution de code à distance sans aucune authentification, qui fonctionne sur une installation WordPress standard, sans extension particulière.

C'est le point qui change tout par rapport aux alertes WordPress habituelles. La quasi-totalité des compromissions WordPress passe d'ordinaire par des plugins ou des thèmes mal maintenus ; cette fois, c'est le cœur du logiciel qui est en cause, sur les versions 6.9.x et 7.0.x. Un site « propre », sans plugin superflu, à jour de ses extensions, est vulnérable exactement comme les autres.

La suite a été très rapide, et c'est le second signal d'alarme : des démonstrations d'exploitation publiques ont circulé dans les jours suivant la publication, et le 21 juillet, l'agence américaine de cybersécurité CISA a inscrit les deux failles à son catalogue KEV, réservé aux vulnérabilités dont l'exploitation active est constatée. Autrement dit, ce n'est plus une menace théorique : des attaquants scannent le web et compromettent des sites en ce moment même. WordPress équipant plus de quatre sites web sur dix dans le monde, la surface d'attaque se compte en centaines de millions de sites.

Les correctifs existent : WordPress 6.9.5 et 7.0.2, publiés en urgence, corrigent l'intégralité de la chaîne.

« Mon site ne sert à rien, il n'y a rien à voler dessus »

C'est l'objection classique, et elle repose sur un malentendu : un attaquant qui compromet votre site vitrine ne cherche généralement pas ce qu'il contient, mais ce qu'il permet. Un site compromis reste le plus souvent visuellement intact — c'est voulu. En coulisses, il devient :

• Une plateforme de phishing à votre nom : les pages frauduleuses sont hébergées sous votre domaine, qui bénéficie de votre réputation et de l'ancienneté de votre nom auprès des filtres anti-spam. Quand la fraude est détectée, c'est votre domaine qui est blacklisté — avec, dans certains cas, vos e-mails professionnels qui cessent d'arriver du jour au lendemain.
• Un point de rebond vers votre système d'information : si le site partage son hébergement avec d'autres services, ou si les mots de passe de l'hébergement se retrouvent aussi ailleurs (messagerie, registrar, FTP), la compromission ne s'arrête pas au site.
• Un relais d'attaque : distribution de malware, minage de cryptomonnaie, participation à des campagnes contre d'autres cibles. Votre serveur travaille pour quelqu'un d'autre, et c'est votre responsabilité juridique qui est engagée vis-à-vis des victimes.
• Une marchandise : les accès à des sites compromis se revendent en lots sur des places de marché spécialisées. L'acheteur décidera plus tard de l'usage.

Les quatre gestes à faire aujourd'hui

1. Identifier vos sites WordPress et leur version. Celui de l'entreprise, mais aussi ceux des filiales, des marques secondaires, des projets abandonnés. La version se lit dans le tableau de bord d'administration, ou dans le code source de la page d'accueil pour un contrôle rapide. Si personne ne sait répondre à la question « qui a la main sur le site ? », c'est déjà un enseignement.
2. Mettre à jour vers 6.9.5 ou 7.0.2 immédiatement. C'est une mise à jour mineure, sans risque significatif de casse, et elle se déploie en quelques minutes. S'il n'y a plus de prestataire ni d'accès admin connu, c'est le moment de régulariser la situation — pas de la reporter.
3. Vérifier que les mises à jour automatiques de sécurité sont actives. WordPress les applique par défaut pour les versions mineures, mais beaucoup d'installations gérées par agence les désactivent. Ce mécanisme est précisément ce qui a protégé les sites bien configurés dans les heures qui ont suivi la publication des correctifs.
4. Rechercher les signes d'une compromission antérieure à la mise à jour. Si votre site est resté vulnérable et exposé après le 17 juillet, la mise à jour ne suffit pas : elle ferme la porte, mais n'expulse pas un intrus déjà entré. Points de contrôle : comptes administrateurs inconnus, fichiers récemment modifiés ou fichiers PHP présents dans les répertoires d'upload, tâches planifiées inhabituelles, trafic sortant inexpliqué. Au moindre doute, une analyse sérieuse s'impose — restaurer une sauvegarde saine antérieure et repartir d'une version corrigée reste souvent la voie la plus sûre.

La leçon de fond : un site web est un actif informatique comme les autres

wp2shell n'est pas un événement isolé, c'est le rappel périodique d'une règle simple : tout ce qui est exposé sur Internet doit avoir un responsable, des mises à jour et une supervision. Le site vitrine échappe souvent aux trois, parce qu'il se situe dans un angle mort — trop « communication » pour l'informatique, trop technique pour la communication.

Concrètement, un site web d'entreprise devrait figurer dans l'inventaire des actifs au même titre qu'un serveur ou un pare-feu, avec : un propriétaire désigné, un cycle de mise à jour (cœur, extensions, thème, PHP), des sauvegardes testées, une supervision qui alerte en cas d'indisponibilité ou de modification anormale, et une procédure claire en cas d'incident. C'est typiquement le genre d'angle mort qu'un audit d'infrastructure met en évidence en quelques heures — et qui coûte infiniment moins cher à corriger avant l'incident qu'après.

En conclusion

Si vous utilisez WordPress en version 6.9 ou 7.0, la question n'est pas de savoir si des attaquants essaieront d'exploiter wp2shell sur votre site, mais s'ils passeront avant ou après votre mise à jour. Le correctif existe, il est gratuit et s'installe en quelques minutes : c'est l'un des rares cas en cybersécurité où le rapport effort/risque est aussi caricatural. Et si cette alerte a révélé qu'aucun nom ne vient à l'esprit quand on demande « qui s'occupe du site ? », c'est le vrai chantier à ouvrir.

Vous voulez faire vérifier l'exposition de votre site, rechercher une éventuelle compromission ou remettre votre présence web sous contrôle (mises à jour, sauvegardes, supervision) ? Parlons-en.