rootdirective-sec/cve-2026-10795-lab
# Docker lab reproduisant CVE-2026-10795 : contournement d'authentification UpdraftPlus UpdraftCentral enchaîné à l'installation de plugin pour une exécution de code à distance (RCE). Inclut des cibles vulnérables/corrigées, un exploit PoC et une analyse pas à pas au niveau du code source.
Ce dépôt contient un laboratoire Docker local permettant de reproduire et de valider la CVE-2026-10795, une vulnérabilité de contournement d'authentification non authentifiée affectant le plugin WordPress UpdraftPlus via sa couche de communication distante UpdraftCentral.
Le comportement vulnérable se situe dans le flux de traitement des messages RPC d'UpdraftCentral. Dans les versions vulnérables, un message RPC falsifié format=1 peut contourner la vérification de signature, déclencher un chemin de déchiffrement RSA en échec, et atteindre tout de même le déchiffrement symétrique avec un comportement prévisible de clé nulle/IV nul. Cela permet à un message RPC chiffré et conçu avec soin d'être accepté et dispatché comme une commande UpdraftCentral.
Ce laboratoire compare deux versions d'UpdraftPlus :
| Service | Version d'UpdraftPlus | Rôle | URL |
|---|---|---|---|
vuln | 1.26.4 | Cible de comparaison vulnérable | http://127.0.0.1:8081 |
patched | 1.26.5 | Cible de comparaison corrigée | http://127.0.0.1:8082 |
La chaîne d'exploitation démontrée est :```text Unauthenticated attacker → forged UpdraftCentral RPC request → format=1 signature verification bypass → failed RSA decrypt not rejected in vulnerable version → predictable zero-key/zero-IV decrypt path → forged JSON RPC command accepted → privileged UpdraftCentral command dispatch → plugin.upload_plugin → install and activate marker plugin → hard-coded /usr/bin/id proof endpoint
La vulnérabilité principale est le contournement de l'authentification. Le laboratoire démontre que ce contournement peut être enchaîné vers un impact de type RCE lorsqu'un état de clé UpdraftCentral privilégié est présent, car UpdraftCentral expose des commandes légitimes de gestion de plugins pouvant installer et activer des plugins WordPress.
Il ne s'agit pas d'une vulnérabilité d'injection directe de commandes. La preuve d'exécution de code provient de l'abus de la fonctionnalité d'installation de plugins authentifiée après avoir contourné la frontière d'authentification RPC.
Ce laboratoire est conçu uniquement pour la recherche locale contrôlée, la compréhension au niveau du code source et la démonstration de portfolio.
## Faits vérifiés
| Affirmation | Preuve | Comment le vérifier dans ce laboratoire |
| ---------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------ |
| UpdraftPlus 1.26.4 est vulnérable dans ce laboratoire. | Le service vulnérable accepte un message RPC `format=1` forgé et déclenche `plugin.upload_plugin`. | Exécutez `python3 poc/poc.py --url http://127.0.0.1:8081`. |
| UpdraftPlus 1.26.5 bloque le message forgé dans ce laboratoire. | Le service corrigé ne renvoie aucun corps de réponse RPC et ne déclenche pas la commande forgée. | Exécutez `python3 poc/poc.py --url http://127.0.0.1:8082`. |
| Le problème est un contournement de l'authentification dans la couche RPC d'UpdraftCentral. | Une requête RPC non authentifiée forgée peut atteindre le déclenchement de commandes dans la version vulnérable. | Comparez le comportement de `--ping` entre les ports `8081` et `8082`. |
| Le laboratoire n'installe pas le plugin marqueur au préalable. | L'installation ne comprend que WordPress, UpdraftPlus et un état de clé UpdraftCentral local. | Vérifiez `/wp-json/cve-lab/v1/id` avant d'exécuter le PoC. |
| Le PoC installe le plugin marqueur via un RPC forgé. | Le PoC envoie `plugin.upload_plugin` avec une charge utile de plugin ZIP dans le champ de données RPC. | Exécutez le PoC puis interrogez `/wp-json/cve-lab/v1/id`. |
| La cible vulnérable atteint un impact de type RCE. | Le plugin marqueur expose un point de terminaison codé en dur qui renvoie la sortie de `/usr/bin/id`. | La cible vulnérable renvoie `uid=33(www-data) gid=33(www-data)`. |
| La cible corrigée n'installe pas le plugin marqueur. | Le point de terminaison du marqueur renvoie `404 rest_no_route` sur le service corrigé. | Exécutez le PoC contre `http://127.0.0.1:8082`. |
| Le laboratoire nécessite un état de clé UpdraftCentral. | Le déclenchement d'UpdraftCentral dépend d'une entrée de clé locale et de métadonnées associées. | Consultez `scripts/setup-wordpress.sh`. |
## Hypothèses et inconnues
Ce laboratoire préconfigure intentionnellement un état de clé UpdraftCentral local afin de reproduire une configuration de site où le contrôle à distance a été configuré.
L'état de clé préconfiguré est un prérequis du laboratoire, et non la vulnérabilité elle-même. Il permet au laboratoire de parcourir de manière cohérente le chemin vulnérable d'analyse et de déchiffrement RPC.
Le laboratoire ne prétend pas que chaque installation d'UpdraftPlus est immédiatement exploitable. La chaîne démontrée dépend de la présence d'une entrée de clé locale UpdraftCentral associée à un utilisateur WordPress privilégié.
Le laboratoire démontre un impact contrôlé de type RCE en installant un plugin marqueur qui expose un point de terminaison de preuve codé en dur renvoyant la sortie de `/usr/bin/id`. Il ne fournit ni shell web générique, ni paramètre d'exécution arbitraire de commandes, ni shell inverse, ni mécanisme de persistance, ni vol d'identifiants, ni rappel externe.
Le PoC est limité aux seules cibles locales et refuse par défaut les noms d'hôtes non locaux.
## Résumé de la cause racine
La cause racine est une validation incorrecte des messages RPC UpdraftCentral dans les versions vulnérables d'UpdraftPlus.
Le flux RPC vulnérable accepte un message `format=1`. Le chemin `format=1` n'exige pas la même vérification de signature que les formats de messages plus récents.
Le problème de haut niveau est :
```text
1. The WordPress site has an UpdraftCentral key state configured.
``````text
format=1 message
→ signature verification is bypassed
→ RSA decrypt of the symmetric key can fail
→ failed decrypt result is not rejected
→ false is passed into the symmetric cipher as a key
→ phpseclib normalizes this into a predictable null key path
→ attacker-controlled encrypted JSON can decrypt successfully
→ command is dispatched
Dans un comportement vulnérable, le déchiffrement RSA peut retourner :```text false
Au lieu de rejeter ce résultat de déchiffrement ayant échoué, le flux vulnérable continue et transmet la valeur à la couche de déchiffrement symétrique.
Le schéma vulnérable effectif est :```php
$sym_key = $rsa->decrypt($sym_key);
$rij->setKey($sym_key);
$decrypted = $rij->decrypt($ciphertext);
Le problème est que $sym_key n'est pas validé avant son utilisation.
Lorsque $sym_key est false, la configuration du chiffrement suit un comportement prévisible de clé nulle/IV nul. Cela permet de concevoir une charge utile RPC chiffrée à l'aide d'une clé zéro et d'un IV zéro connus.
La version corrigée ajoute une vérification avant l'utilisation de la clé symétrique :```php if (false === $sym_key || !is_string($sym_key) || strlen($sym_key) < 16) { return false; }
Cela modifie la frontière de confiance.