rootdirective-sec/cve-2026-10795-labDocker-Labor, das CVE-2026-10795 reproduziert: Authentifizierungsumgehung in UpdraftPlus UpdraftCentral, verkettet mit Plugin-Installation für RCE. Enthält verwundbare/gepatchte Ziele, PoC-Exploit und Quellcode-Walkthrough.
Dieses Repository enthält ein lokales Docker-Lab zur Reproduktion und Validierung von CVE-2026-10795, einer nicht authentifizierten Authentifizierungsumgehungsschwachstelle, die das UpdraftPlus WordPress-Plugin über seine UpdraftCentral-Fernkommunikationsschicht betrifft.
Das angreifbare Verhalten existiert im UpdraftCentral RPC-Nachrichtenverarbeitungsablauf. In anfälligen Versionen kann eine gefälschte format=1 RPC-Nachricht die Signaturprüfung umgehen, einen fehlgeschlagenen RSA-Entschlüsselungspfad auslösen und dennoch die symmetrische Entschlüsselung mit einem vorhersagbaren Null-Schlüssel-/Null-IV-Verhalten erreichen. Dies ermöglicht es, dass eine manipulierte verschlüsselte RPC-Nachricht als UpdraftCentral-Befehl akzeptiert und weitergeleitet wird.
Dieses Lab vergleicht zwei UpdraftPlus-Versionen:
| Dienst | UpdraftPlus-Version | Zweck | URL |
|---|---|---|---|
vuln | 1.26.4 | Angreifbares Vergleichsziel | http://127.0.0.1:8081 |
patched | 1.26.5 | Gepatchtes Vergleichsziel | http://127.0.0.1:8082 |
Die demonstrierte Kette ist:```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
Die primäre Schwachstelle ist ein Authentifizierungs-Bypass. Die Laborumgebung zeigt, dass der Bypass zu einem RCE-ähnlichen Impact ausgenutzt werden kann, wenn ein privilegierter UpdraftCentral-Schlüsselstatus vorhanden ist, da UpdraftCentral legitime Plugin-Management-Befehle bereitstellt, die WordPress-Plugins installieren und aktivieren können.
Dies ist keine direkte Befehlsinjizierungsschwachstelle. Der Code-Ausführungsnachweis erfolgt durch Missbrauch der authentifizierten Plugin-Installationsfunktion nach Umgehung der RPC-Authentifizierungsgrenze.
Diese Laborumgebung ist ausschließlich für kontrollierte lokale Forschung, Quellcode-Verständnis und Demonstrationszwecke im Portfolio gedacht.
## Verifizierte Fakten
| Behauptung | Nachweis | So überprüfen Sie es in diesem Labor |
| -------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------- |
| UpdraftPlus 1.26.4 ist in diesem Labor verwundbar. | Der verwundbare Dienst akzeptiert eine gefälschte `format=1` RPC-Nachricht und führt `plugin.upload_plugin` aus. | Führen Sie `python3 poc/poc.py --url http://127.0.0.1:8081` aus. |
| UpdraftPlus 1.26.5 blockiert die gefälschte Nachricht in diesem Labor. | Der gepatchte Dienst gibt keinen RPC-Antworttext zurück und führt den gefälschten Befehl nicht aus. | Führen Sie `python3 poc/poc.py --url http://127.0.0.1:8082` aus. |
| Das Problem ist ein Authentifizierungs-Bypass in der UpdraftCentral-RPC-Ebene. | Eine gefälschte, nicht authentifizierte RPC-Anfrage kann in der verwundbaren Version die Befehlsverteilung erreichen. | Vergleichen Sie das `--ping`-Verhalten zwischen den Ports `8081` und `8082`. |
| Das Labor installiert das Markierungs-Plugin nicht vor. | Die Einrichtung installiert nur WordPress, UpdraftPlus und einen lokalen UpdraftCentral-Schlüsselstatus. | Überprüfen Sie `/wp-json/cve-lab/v1/id` vor dem Ausführen des PoC. |
| Der PoC installiert das Markierungs-Plugin durch eine gefälschte RPC. | Der PoC sendet `plugin.upload_plugin` mit einem ZIP-Plugin-Payload im RPC-Datenfeld. | Führen Sie den PoC aus und fragen Sie dann `/wp-json/cve-lab/v1/id` ab. |
| Das verwundbare Ziel erreicht einen RCE-ähnlichen Impact. | Das Markierungs-Plugin legt einen fest codierten Endpunkt frei, der die Ausgabe von `/usr/bin/id` zurückgibt. | Das verwundbare Ziel gibt `uid=33(www-data) gid=33(www-data)` zurück. |
| Das gepatchte Ziel installiert das Markierungs-Plugin nicht. | Der Markierungs-Endpunkt gibt auf dem gepatchten Dienst `404 rest_no_route` zurück. | Führen Sie den PoC gegen `http://127.0.0.1:8082` aus. |
| Das Labor erfordert einen UpdraftCentral-Schlüsselstatus. | Die UpdraftCentral-Befehlsverteilung hängt von einem lokalen Schlüsseleintrag und zugehörigen Metadaten ab. | Überprüfen Sie `scripts/setup-wordpress.sh`. |
## Annahmen und Unbekanntes
Dieses Labor legt absichtlich einen lokalen UpdraftCentral-Schlüsselstatus an, um einen Site-Zustand zu reproduzieren, in dem die Fernsteuerung konfiguriert wurde.
Der angelegte Schlüsselstatus ist eine Voraussetzung des Labors, nicht die Schwachstelle selbst. Er ermöglicht es dem Labor, den verwundbaren RPC-Parsing- und Entschlüsselungspfad konsistent zu durchlaufen.
Das Labor behauptet nicht, dass jede UpdraftPlus-Installation sofort ausnutzbar ist. Die demonstrierte Kette hängt vom Vorhandensein eines lokalen UpdraftCentral-Schlüsseleintrags ab, der mit einem privilegierten WordPress-Benutzer verknüpft ist.
Das Labor demonstriert einen kontrollierten RCE-ähnlichen Impact durch die Installation eines Markierungs-Plugins, das einen fest codierten `/usr/bin/id`-Nachweis-Endpunkt freigibt. Es stellt keine generische Web-Shell, keinen Parameter zur beliebigen Befehlsausführung, keinen Reverse-Shell, keinen Persistenzmechanismus, keinen Diebstahl von Anmeldeinformationen und keinen externen Callback bereit.
Der PoC ist auf lokale Ziele beschränkt und lehnt standardmäßig nicht-lokale Hostnamen ab.
## Zusammenfassung der Grundursache
Die Grundursache ist eine unsachgemäße Validierung von UpdraftCentral-RPC-Nachrichten in verwundbaren Versionen von UpdraftPlus.
Der verwundbare RPC-Fluss akzeptiert eine `format=1`-Nachricht. Der `format=1`-Pfad erfordert nicht dieselbe Signaturprüfung wie neuere Nachrichtenformate.
Das Problem auf hoher Ebene ist:```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
Bei anfälligem Verhalten kann die RSA-Entschlüsselung Folgendes zurückgeben:```text false
Statt dieses fehlgeschlagene Entschlüsselungsergebnis abzulehnen, setzt der anfällige Ablauf fort und übergibt den Wert an die symmetrische Entschlüsselungsschicht.
Das effektive anfällige Muster ist:```php
$sym_key = $rsa->decrypt($sym_key);
$rij->setKey($sym_key);
$decrypted = $rij->decrypt($ciphertext);
Das Problem ist, dass $sym_key nicht validiert wird, bevor es verwendet wird.
Wenn $sym_key false ist, folgt die Cipher-Einrichtung einem vorhersagbaren Null-Schlüssel/Null-IV-Verhalten. Dies macht es möglich, einen verschlüsselten RPC-Payload mit einem bekannten Null-Schlüssel und Null-IV zu erstellen.
Die gepatchte Version fügt eine Prüfung hinzu, bevor der symmetrische Schlüssel verwendet wird:```php if (false === $sym_key || !is_string($sym_key) || strlen($sym_key) < 16) { return false; }
Dies ändert die Vertrauensgrenze.