Click2Shell : one-click vers l'exécution de code sur WordPress
La chaîne baptisée "Click2Shell" combine une injection de sélecteur jQuery dans le core WordPress avec une faille d'un thème tiers pour transformer un simple clic d'administrateur en exécution de code à distance.
Aucun CVE n'a encore été attribué et aucune exploitation active n'a été observée, mais le correctif publié dans WordPress 7.1.1 le 17 septembre 2026 doit être appliqué sans délai, tant la primitive de départ touche potentiellement toute installation antérieure du CMS le
plus déployé au monde.
Synthèse rapide
Nom : "Click2Shell", découverte par le chercheur Paulos Yibelo (pwn.ai)
CVE : non attribué à ce jour ; WordPress a indiqué qu'un identifiant serait publié ultérieurement
CVSS : pwn.ai évalue la primitive isolée à 7,1 (High) et la chaîne complète à 9,3 (Critical) ; The Hacker News rapporte un score de 9,6
Type : CSRF sur le core WordPress → injection de sélecteur jQuery → installation forcée de thème → chargement de code PHP pré-activation via le Customizer → upload de fichier non restreint dans un thème tiers → RCE
Versions affectées : toutes les versions de WordPress antérieures à 7.1.1
Statut : correctif publié le 17 septembre 2026 dans WordPress 7.1.1 (changeset 63664) ; aucune exploitation en conditions réelles rapportée à ce jour
Prérequis d'exploitation : un administrateur doit être connecté et ouvrir un lien piégé (ou être exposé via un XSS préexistant sur le site).
Ce n'est pas une RCE non authentifiée déclenchable à distance sans interaction mais un “one-click exploit” ciblant les administrateurs
Chronologie
Date | Évènement |
22 août 2026 | pwn.ai signale à WordPress l'injection de sélecteur du core forçant l'installation d'un thème, avec un PoC navigateur fonctionnel |
22 août 2026 | WordPress reproduit le comportement sur la version 7.1.0 et engage un correctif de durcissement |
1er septembre 2026 | pwn.ai transmet la chaîne complète, incluant le chargement pré-activation du Customizer et la faille du thème tiers Mobile Repair Zone 2.5.4, avec une preuve d'exécution PHP |
Septembre 2026 | WordPress verse sa prime de bug bounty maximale au chercheur et planifie une version de sécurité |
17 septembre 2026 | Publication de WordPress 7.1.1, correctif du sélecteur jQuery (changeset 63664), pwn.ai et Paulos Yibelo crédités dans les notes de version |
18 septembre 2026 | Divulgation technique complète par pwn.ai et couverture par Patchstack et la presse spécialisée |
Analyse technique
Le back-office de WordPress permet à un administrateur d'installer un thème du catalogue officiel WordPress.org directement depuis l'interface, sans quitter l'admin. Ce flux transmet le slug du thème dans l'URL, et cette même valeur est interprétée deux fois, par deux composants qui ne la traitent pas de la même façon.
Côté serveur, l'API Themes de WordPress.org canonicalise la valeur : les caractères parasites sont éliminés, si bien qu'une chaîne comme twentytwenty"]>*>*>*/* se réduit à twentytwenty et l'API renvoie la fiche légitime de ce thème.
Côté navigateur en revanche, le JavaScript du back-office (wp-admin/js/theme.js) réutilise la valeur brute d'origine et l'injecte sans échappement dans une chaîne de sélecteur jQuery :
$( 'div[data-slug="' + slug + '"]' ).trigger( 'click' );Avec la valeur piégée, le sélecteur généré devient div[data-slug="twentytwenty">*>*>*/*"] : le guillemet injecté referme prématurément le sélecteur d'attribut, les combinateurs enfants > permettent ensuite de descendre dans l'arborescence de la carte du thème jusqu'aux boutons d'action, et le commentaire CSS final neutralise le fragment résiduel ajouté par WordPress. Le .trigger('click') déclenche alors le vrai bouton Install.
L'attaquant n'a besoin ni du nonce d'installation ni de la capacité install_themes : c'est la page d'admin de confiance elle-même qui fournit le nonce, et l'administrateur victime qui fournit les privilèges. Le propre code JavaScript de WordPress dépense les deux pour le compte de l'attaquant. Cette seule primitive permet déjà de forcer l'installation silencieuse de n'importe quel thème du catalogue officiel, sans que l'interface visible du site ne change puisque le thème reste inactif.
C'est ce second maillon qui transforme la primitive en exécution de code. Un thème installé mais non activé est en principe inerte, à une exception près : la prévisualisation dans le Customizer charge le functions.php du thème même lorsqu'il n'est pas actif, via une requête du type admin-ajax.php?wp_customize=on&customize_theme=<slug>. pwn.ai a identifié que le thème du catalogue officiel Mobile Repair Zone, en version 2.5.4, enregistre à ce stade un handler AJAX authentifié qui installe et active des plugins à partir d'une URL fournie par la requête, sans vérification de nonce ni de capacité :
add_action(
'wp_ajax_mobile_repair_zone_install_and_activate_plugin',
'mobile_repair_zone_install_and_activate_plugin'
);Ce handler récupère l'URL du plugin transmise dans plugin_details[plugin_url], télécharge l'archive, la décompresse dans le répertoire des plugins et charge son point d'entrée : c'est l'exécution de code PHP côté serveur.
pwn.ai signale avoir repéré plus de 40 thèmes tiers hébergés sur le catalogue officiel présentant des faiblesses comparables, ce qui élargit potentiellement les vecteurs de chaînage au-delà de ce seul exemple.
Il est important de noter que le bug du core, pris isolément, n'accepte pas un thème arbitraire fourni par l'attaquant : il installe uniquement un thème existant du catalogue officiel. C'est le chaînage avec la faille du thème tiers qui produit la RCE.
Le correctif livré dans la 7.1.1 agit à la source de la désynchronisation : il restreint la correspondance du sélecteur aux véritables cartes de thème (div.theme) et échappe le slug issu de l'URL avant de l'insérer dans le sélecteur, via $.escapeSelector(). Le guillemet, les combinateurs et le commentaire injectés sont désormais traités comme du texte littéral et ne peuvent plus casser la structure du sélecteur.
Preuve de concept (PoC)
pwn.ai a publié une démonstration en deux étapes, à ne reproduire que sur une instance de test dont vous êtes propriétaire. La première étape isole la primitive de forced install : sur un site où le thème twentytwenty n'est pas installé, un administrateur connecté ouvre l'URL wp-admin/theme-install.php?theme=twentytwenty%22%5D%3E%2A%3E%2A%3E%2A%2F%2A - le slug encodé correspondant à twentytwenty"]>*>*>*/*.
WordPress interroge le catalogue, reçoit la fiche légitime du thème, déclenche le contrôle d'installation et écrit le thème sur le disque, sans qu'aucun changement visible n'apparaisse côté visiteur. La seconde étape enchaîne la chaîne complète : une page contrôlée par l'attaquant ouvre l'URL d'installation piégée pointant cette fois vers le thème Mobile Repair Zone, laisse le temps à l'administrateur de rester connecté, puis soumet automatiquement une requête vers admin-ajax.php?wp_customize=on&customize_theme=mobile-repair-zone avec l'action mobile_repair_zone_install_and_activate_plugin et une URL de plugin malveillant. Le code de démonstration de pwn.ai exécute une simple commande id pour prouver l'exécution.
Des reconstructions de ce PoC ont depuis été publiées publiquement sur GitHub (dépôts Usman0220/click2shell-poc et HackfutSecRoot/click2shell), décomposant les trois primitives de la chaîne. Il s'agit de reconstructions tierces réalisées à partir de la divulgation publique ; le PoC de référence demeure celui de pwn.ai.
Impact
Une installation de thème est une opération de déploiement de code hautement privilégiée. Dès l'étape de forced install, avant même toute exécution PHP, un attaquant peut déjà placer du code exécutable sous l'application web. Une fois la chaîne complète aboutie, pwn.ai décrit un accès permettant de lire wp-config.php et les identifiants de base de données, d'accéder aux données WordPress ou WooCommerce et à celles des plugins installés, de créer ou modifier des comptes utilisateurs et du contenu, de lire les secrets accessibles au worker PHP, d'altérer des fichiers et, in fine, de prendre le contrôle total de l'installation ou du serveur qui l'héberge.
Sur le plan réglementaire, une RCE aboutie sur un site WordPress traitant des données personnelles (comptes clients, adresses e-mail, données de commande WooCommerce, formulaires de contact) constitue une violation de données au sens de l'article 4(12) du RGPD. Le règlement impose au responsable de traitement de notifier l'autorité de contrôle compétente sans délai excessif et, si possible, dans les 72 heures suivant la prise de connaissance de l'incident, sauf si la violation n'est pas susceptible d'engendrer un risque pour les droits et libertés des personnes concernées (article 33).
Lorsque le risque est élevé, l'information des personnes concernées elles-mêmes s'impose également, sans délai excessif (article 34). L'accès potentiel à wp-config.php, qui contient les clés d'authentification et les identifiants de base de données, ainsi que la possibilité d'exfiltrer des bases utilisateurs, alourdissent la qualification de l'incident et justifient une documentation rigoureuse de la fenêtre d'exposition.
Le contexte de surface reste considérable en volume, même si les prérequis d'exploitation le tempèrent fortement. WordPress équipe, selon W3Techs, 43,4 % de l'ensemble des sites web recensés ; rapporté au décompte de sites actifs publié par Netcraft, cela représente de l'ordre de 500 millions d'installations WordPress dans le monde, un ordre de grandeur également avancé par pwn.ai.
Contrairement à des chaînes non authentifiées comme wp2shell, Click2Shell nécessite qu'un administrateur connecté ouvre un lien piégé ou soit exposé via un XSS existant sur le site, ce qui réduit fortement le potentiel d'exploitation de masse par rapport à une RCE pré-authentification classique.
Indicateurs de détection
Aucun éditeur n'a publié à ce jour de signatures WAF ni de liste d'indicateurs réseau spécifiques à Click2Shell, et The Hacker News confirme l'absence de signe d'exploitation en conditions réelles. Les indicateurs qui suivent découlent de l'analyse technique de la chaîne et doivent être adaptés à votre environnement.
Journaux d'accès web (Apache/Nginx)
requêtes GET vers /wp-admin/theme-install.php?theme= contenant la signature de breakout de sélecteur encodée : %22%5D%3E (soit "]>), suivie de combinateurs %3E et d'un commentaire %2F%2A
requêtes vers /wp-admin/admin-ajax.php?wp_customize=on&customize_theme=<slug> sur un site où le Customizer n'est pas utilisé de façon interactive habituelle
requêtes POST vers admin-ajax.php portant action=mobile_repair_zone_install_and_activate_plugin (ou une action AJAX équivalente d'un autre thème) avec un champ plugin_details[plugin_url] pointant vers un domaine externe
Intégrité des fichiers
apparition d'un nouveau répertoire de thème sous wp-content/themes/, resté inactif, alors que le thème visible du site n'a pas changé.
C'est précisément ce qui rend l'attaque furtive à ce stade
apparition d'un nouveau répertoire de plugin sous wp-content/plugins/ hors process de déploiement habituel
fichiers PHP récemment modifiés, à rechercher par exemple avec find /var/www/.../wp-content -name "*.php" -mtime -7 -ls
Threat hunting complémentaire
vérifier que les mises à jour automatiques de sécurité se sont effectivement appliquées
passer en revue les thèmes et plugins récemment installés, y compris ceux jamais activés
inspecter les comptes administrateurs créés récemment et les modifications de rôles
Recommandations
Administrateurs Wordpress
Mettre à jour vers WordPress 7.1.1 (ou la version rétroportée correspondant à votre branche : les correctifs remontent jusqu'à la 4.7, par exemple 7.0.5, 6.9.8 ou 6.8.9 selon la documentation officielle). Vérifier explicitement que la mise à jour automatique s'est bien appliquée, ces mécanismes échouant parfois silencieusement.
Si une mise à jour immédiate est impossible, activer la constante DISALLOW_FILE_MODS dans wp-config.php. Elle bloque l'installation de nouveaux thèmes et plugins depuis l'interface d'administration et casse donc l'un des maillons de la chaîne. Cette mesure bloque en contrepartie les mises à jour légitimes de thèmes et plugins tant qu'elle reste active.
Sensibiliser les administrateurs à ne pas ouvrir de liens wp-admin/theme-install.php?theme=… non sollicités pendant qu'ils sont connectés à l'espace d'administration.
Corriger tout XSS préexistant sur le site, celui-ci pouvant servir de vecteur d'auto-déclenchement du CSRF depuis le navigateur d'un administrateur légitime, sans nécessiter de lien envoyé explicitement.
Déployer des règles WAF bloquant les requêtes vers theme-install.php dont le paramètre theme contient un guillemet suivi d'un chevron ("]>) ou des combinateurs CSS.
Durcissez votre Wordpress, par exemple en interdisant l’énumération des utilisateurs, ce qui limite les risques de tentatives de phishing / XSS sur des administrateurs ciblés
Éditeurs et intégrateurs WordPress
Déployer la 7.1.1 sur l'ensemble des sites gérés, y compris les environnements de staging, les sites marketing secondaires et les filiales parfois oubliées des cycles de mise à jour.
Auditer les thèmes tiers exposant des handlers AJAX (wp_ajax_*) sans vérification de nonce ni de capacité utilisateur : Mobile Repair Zone n'est qu'un exemple parmi la quarantaine de thèmes signalés par pwn.ai comme présentant des faiblesses comparables.
Généraliser l'échappement systématique des entrées lues à la fois côté serveur et côté client, la désynchronisation entre ces deux traitements étant précisément à l'origine de la faille du core.
Si un CVE officiel est publié et que des éditeurs comme Wordfence ou WPScan émettent une signature dédiée, réévaluer la priorité de patch des sites restants à la lumière de cette confirmation.
SOC / Blue Team
Déployer les détections de journaux décrites plus haut, en particulier les motifs d'injection sur theme-install.php et les requêtes vers admin-ajax.php?wp_customize=on.
Renforcer la surveillance d'intégrité de fichiers sur wp-content/themes/ et wp-content/plugins/, avec une alerte sur toute apparition de répertoire inactif.
Considérer toute correspondance de pattern d'injection combinée à l'apparition d'un nouveau répertoire de plugin comme un incident présumé justifiant une escalade vers la réponse à incident.
Réponse à incident
Préserver les journaux avant tout nettoyage, la fenêtre d'exposition couvrant toutes les versions antérieures à la 7.1.1 jusqu'à l'application effective du correctif.
Rechercher webshells, comptes administrateurs non autorisés, Application Passwords suspectes et tâches cron malveillantes, en gardant à l'esprit qu'un site WordPress apparemment propre ne garantit pas un serveur propre.
Procéder à la rotation des secrets exposés (clés d'authentification et sels définis dans wp-config.php, identifiants de base de données) en cas de compromission confirmée.
Évaluer l'obligation de notification RGPD sous 72 heures et, le cas échéant, l'information des personnes concernées si des données personnelles ont pu être exposées durant la fenêtre de compromission.
Conclusion et suite
Aucun CVE n'a été attribué à Click2Shell au moment de la rédaction ; toute référence ultérieure à un identifiant devra être vérifiée dans le NVD ou les GitHub Security Advisories.
Les scores CVSS cités restent des estimations du chercheur, WordPress n'ayant pas publié de sévérité officielle. À ce stade, aucune exploitation en conditions réelles n'a été rapportée, et Patchstack demeure le principal acteur de la sécurité WordPress à avoir publié une couverture dédiée, aux côtés de la divulgation de pwn.ai elle-même .
Ni Wordfence ni Sucuri ni WPScan n'ont émis d'avis spécifique à cette faille à ce jour, ce qui s'explique vraisemblablement par l'absence d'exploitation observée et par des prérequis d'exploitation contraignants. Il convient enfin de distinguer clairement Click2Shell d'autres chaînes récentes touchant le core WordPress découvertes par le même laboratoire ou des tiers, notamment wp2shell (RCE non authentifiée via l'API REST batch, activement exploitée et référencée au catalogue KEV de la CISA) et XSS2Shell, qui reposent sur des mécanismes distincts.
Sources : pwn.ai (Paulos Yibelo), Patchstack, WordPress.org (notes de version 7.1.1), The Hacker News.
