Comment cela fonctionne-t-il ?

En quoi ce PoC diffère des exploits wp2shell publics

tous les PoC exploitent les deux mêmes bugs - la confusion de route REST par lot (CVE-2026-63030) et l'injection SQL author__not_in (CVE-2026-60137) - avec la même forme de lot doublement imbriqué. Ce qui diffère entre eux est le chemin RCE choisi, les préconditions d'environnement et les paramètres de sécurité par défaut. Ce document indique concrètement où se situe l'implémentation de ce dépôt dans ce paysage.

La version courte

1. Fonctionne derrière un cache d'objets persistant. Les PoC publics basés sur UNION utilisent la forme d'injection à base remplie : l'implémentation de chaîne complète que cette lignée partage produit des faux négatifs, et le fichier unificateur unique liste "pas de cache d'objets persistant" comme précondition explicite. La forme à base vidée de ce dépôt maintient le canal UNION - et donc l'ensemble du pont RCE pré-authentification - en vie sur exactement ces hôtes (la configuration WordPress managée courante). Voir §1.
2. Sûr à exécuter contre la production par défaut. check n'envoie aucune charge utile SQL sauf demande explicite ; tout le trafic peut porter une balise d'attribution ; tout ce que la commande shell écrit sur la cible est automatiquement supprimé ensuite. Voir §3.

Tableau comparatif

[1] Lecture uniquement temporelle/aveugle comme canal de lecture ; la primitive de faux message UNION existe à l'intérieur du pont mais n'est pas exposée comme oracle d'extraction. [2] La sonde de disponibilité naïve (0) UNION SELECT …) est silencieusement abandonnée pendant l'hydratation du cache d'objets, available() retourne faux, et tout le pont pré-authentification échoue - voir §1. [3] Le README du projet liste "pas de cache d'objets persistant (Redis/Memcached)" sous Préconditions. [4] Variante publique miroir sur Sploitus (lien ci-dessous) : lecture aveugle plus un dropper INTO OUTFILE comme étape RCE, utilisant un conteneur per_page=-1 categories. [5] Le chemin RCE OUTFILE ne dépend pas du rendu des faux messages, donc les caches d'objets ne le bloquent pas - ce sont le privilège MySQL FILE et un répertoire partagé accessible en écriture qui le font. L'hébergement managé n'accorde presque jamais FILE à l'utilisateur WordPress de la base de données, et secure_file_priv est souvent défini.

1. Le problème du cache d'objets (le véritable différenciateur)

La primitive de faux message UNION dépend de la façon dont WP_Query retourne les lignes :

• Mode ligne complète - le SQL retourne des lignes entières de wp_posts ; une ligne injectée par UNION devient un WP_Post directement. Le faux message est rendu.
• Mode fractionné (ID uniquement) - le SQL retourne uniquement des ID, et chaque ID est hydraté ensuite via le cache d'objets persistant / la base de données. L'ID de la ligne forgée n'existe pas, donc l'hydratation l'abandonne silencieusement. Pas d'erreur, pas de faux message.

Sur les hôtes avec un cache d'objets persistant, un jeu de résultats de base rempli pousse WP_Query en mode fractionné. La sonde standard utilisée par les PoC publics -

0) UNION SELECT <ligne forgée> -- -

• laisse l'ensemble de base rempli (post_author NOT IN (0) correspond à chaque ligne), donc derrière un cache d'objets le faux message s'évapore : la sonde de disponibilité fait un faux négatif, available() retourne faux, et tout le pont pré-authentification est signalé "mort" sur un hôte qui est en fait entièrement exploitable. Le fichier unificateur public documente la même limite en listant "pas de cache d'objets persistant" comme une précondition stricte.

Ce dépôt vide l'ensemble de base à la place :

1) AND 1=0 UNION ALL SELECT <ligne forgée> -- -

Avec zéro ligne de base, la ligne forgée est la seule ligne ; la requête reste en mode ligne complète ; aucune recherche d'hydratation n'est jamais exécutée. Un mot-clé injecté (AND 1=0) est toute la différence entre "canal UNION mort" et "RCE complète pré-authentification" sur les hôtes avec cache d'objets - qui sont la majorité des environnements WordPress de production managés. Le diagnostic, la matrice de sondes (per_page × forme d'injection).

Note de portée : le canal de lecture aveugle/temporel n'est pas sensible au cache d'objets (compter les lignes en SQL n'implique pas l'hydratation des faux messages), donc la lecture aveugle de chaque PoC fonctionne partout. Ce que le cache d'objets tue dans les autres PoC est spécifiquement la partie dépendante de UNION : l'extraction en bande et le pont SQLi-à-admin.

Une deuxième leçon connexe documentée dans l'étude de cas : lorsque les deux canaux fonctionnent, traitez la lecture UNION en bande comme faisant autorité - l'oracle temporel de production a produit des inversions de bits sous gigue sur une valeur que la lecture en bande a établie sans ambiguïté.

2. Choix du chemin RCE

Trois chemins RCE pré-authentification existent dans les PoC publics :

Ce dépôt implémente le pont : il n'a besoin d'aucun privilège de base de données au-delà de ce que WordPress a déjà, fonctionne lorsque les couches base et web ne partagent rien, et ne laisse aucun fichier pour le chemin du privilège FILE. Le compromis est la complexité - le pont est un graphe de messages empoisonnés sur sept lignes - ce qui est exactement là où le faux négatif du cache d'objets §1 cachait le chemin.

3. Paramètres de sécurité par défaut pour une utilisation autorisée

Construit pour être exécuté contre des systèmes de production sous autorisation, pas seulement en laboratoire :

• check est non destructif par défaut - empreinte passive plus un lot de marqueur bénin ; aucune charge utile SQL n'est envoyée sauf si --confirm-sqli est donné. Après le correctif, le triplet de marqueurs qui disparaît sert également de validation de correctif.
• Marquage d'attribution - --user-agent sur chaque commande pour que tout le trafic d'exploitation soit identifiable dans les journaux (une règle de conduite que les outils publics n'activent pas par défaut).
• Nettoyage automatique - le webshell est verrouillé par jeton sous un chemin aléatoire et se supprime lui-même ; un administrateur créé par le pont est supprimé ensuite et son contenu est réaffecté au compte administrateur emprunté. L'échec du nettoyage est signalé bruyamment, pas avalé.
• Comptabilité des requêtes - chaque commande affiche combien de requêtes elle a envoyées.

4. Ce que ce dépôt ne prétend pas

• Aucune nouvelle vulnérabilité. Les deux bugs sont les CVE publiquement divulguées ; la forme de lot doublement imbriqué, le sink author_exclude → author__not_in, la primitive UNION de faux WP_Post, et le concept de pont customizer sont tous des techniques publiques (lignée reconnue ci-dessous).
• Aucune nouvelle primitive d'exploitation. Le delta par rapport au paysage public est : le correctif du cache d'objets avec base vidée et preuve de production, les paramètres de sécurité pour la production, et la documentation de détection - robustesse et sécurité opérationnelle, pas nouveauté de technique.
• Les chaînes IoC sont arbitraires. Les préfixes de connexion, les slugs de plugins, les marqueurs de shell et les valeurs User-Agent diffèrent d'une variante à l'autre et d'une exécution à l'autre ;

Références

• Icex0/wp2shell-poc - implémentation de chaîne complète dont ce dépôt partage la lignée - https://github.com/Icex0/wp2shell-poc
• sergiointel/wp2shell-poc - premier PoC public ; origine de la technique de création d'admin sans cassage - https://github.com/sergiointel/wp2shell-poc
• 0xsha/wp2shell - fichier unificateur unique de six PoC publics, avec laboratoires Docker et une matrice version×base de données (documente la précondition du cache d'objets) - https://github.com/0xsha/wp2shell
• Variante OUTFILE (lecture aveugle + dropper INTO OUTFILE), miroir sur Sploitus - https://sploitus.com/exploit?id=7CD079AD-E27B-5C54-A696-60635BFDB241
• Liste organisée de PoC publics et de vérificateurs (pour les défenseurs) - https://www.cyberkendra.com/2026/07/wp2shell-guide.html
• GHSA-ff9f-jf42-662q / GHSA-fpp7-x2x2-2mjf ; annonce de la version WordPress 7.0.2 - voir les références dans README.md.