rootdirective-sec/cve-2026-3844-labLokales Docker-Labor zur Reproduktion von CVE-2026-3844, einem nicht authentifizierten beliebigen Datei-Upload zu RCE im WordPress Breeze Cache Plugin. Vergleicht verwundbare 2.4.4 mit gepatchter 2.4.5 unter Verwendung isolierter Dienste und eines minimal schädlichen PoC.
Reines lokales Docker-Lab zur Reproduktion und zum Vergleich des Verhaltens von CVE-2026-3844 im WordPress-Breeze-Cache-Plugin.
Dieses Repository demonstriert das verwundbare Verhalten in Breeze Cache 2.4.4 und vergleicht es mit dem gepatchten Verhalten in Breeze Cache 2.4.5. Das Lab verwendet zwei isolierte WordPress-Dienste, einen verwundbaren und einen gepatchten, sowie einen lokalen Payload-Server innerhalb des Docker-Netzwerks.
Der Proof of Concept ist bewusst auf minimalen Schaden ausgelegt: Er verwendet keine Webshell, legt keinen Befehls-Parameter offen, startet keine Reverse Shell und erfordert kein Lesen von Dateien aus dem Container. Der Nachweis basiert auf beobachtbarem HTTP-Verhalten vom Host aus.
CVE-2026-3844 betrifft das Breeze-Cache-Plugin für WordPress bis einschließlich Version 2.4.4. Der verwundbare Codepfad steht im Zusammenhang mit der lokalen Gravatar-Caching-Funktion des Plugins, insbesondere mit dem Ablauf von fetch_gravatar_from_remote().
Wenn die Breeze-Option Host Files Locally - Gravatars aktiviert ist, können verwundbare Versionen eine angreiferkontrollierte Remote-Datei abrufen und in einem öffentlich über das Web zugänglichen Cache-Verzeichnis speichern. Handelt es sich bei der abgerufenen Datei um PHP, kann die Datei vom Webserver ausgeführt werden, wenn sie über HTTP angefordert wird.
Dieses Lab reproduziert dieses Verhalten lokal:
vuln-Dienst: WordPress + Breeze Cache 2.4.4patched-Dienst: WordPress + Breeze Cache 2.4.5payload-Dienst: lokaler Payload-Server, nur innerhalb von Docker erreichbarsrcset-ZeichenketteDas erwartete Ergebnis ist:
http://127.0.0.1:8081 / Breeze 2.4.4 → Proof-PHP wird zwischengespeichert und ausgeführthttp://127.0.0.1:8082 / Breeze 2.4.5 → Proof-PHP ist weder zwischengespeichert noch lesbar noch ausführbar.
├── docker-compose.yml
├── vuln/
│ └── Dockerfile
├── patched/
│ └── Dockerfile
├── scripts/
│ └── seed-wordpress.sh
├── payload/
│ └── manual-proof.php
│ └── proof-cve3844.php
├── poc/
│ └── poc.py
│ └── requirements.txt
├── .gitignore
├── README.md
Host machine
│
├── http://127.0.0.1:8081 -> vuln WordPress + Breeze 2.4.4
├── http://127.0.0.1:8082 -> patched WordPress + Breeze 2.4.5
└── http://127.0.0.1:9100 -> local payload server
Docker network
│
├── vuln -> WordPress vulnerable target
├── patched -> WordPress patched target
├── vuln_db -> MariaDB for vulnerable WordPress
├── patched_db -> MariaDB for patched WordPress
└── payload -> Python static HTTP server
Die WordPress-Container rufen den Payload über die Docker-Netzwerk-URL ab:
http://payload:9100/<payload-file>.php
Der Host verifiziert das Ergebnis über normale HTTP-Anfragen an die WordPress-Dienste.
2.4.42.4.5fetch_gravatar_from_remote()inc/class-breeze-cache-cronjobs.phpbreeze-store-gravatars-locally muss aktiviert seinDas verwundbare Verhalten ist nur erreichbar, wenn das lokale Gravatar-Caching aktiviert ist. Diese Option ist in typischen Installationen standardmäßig deaktiviert, dieses Lab aktiviert sie jedoch absichtlich, um den verwundbaren Codepfad zu reproduzieren.
In Breeze Cache 2.4.4 kann der Gravatar-Lokalisierungsablauf eine Remote-URL aus avatarbezogenem HTML extrahieren und diese URL an fetch_gravatar_from_remote() übergeben.
Die verwundbare Version weist keine ausreichende Validierung der Remote-Datei auf:
.php behaltenDie resultierende Datei wird gespeichert unter:
/wp-content/cache/breeze-extra/gravatars/
Wenn eine PHP-Datei dort gespeichert und anschließend über Apache/PHP angefordert wird, führt der Server sie aus.
In Breeze Cache 2.4.5 fügt der gepatchte Ablauf eine Validierung hinzu, die verhindert, dass dieser Lab-Payload als ausführbares PHP zwischengespeichert wird. In der lokalen Reproduktion funktioniert derselbe Auslöser gegen 2.4.4, legt den Proof-Marker gegen 2.4.5 jedoch nicht offen.
Dieses Lab betreibt den Payload-Server bewusst lokal, anstatt einen öffentlichen Payload-Host zu verwenden.
WordPress download_url() und die WordPress-HTTP-API lehnen standardmäßig einige private Docker-Hostnamen und nicht standardmäßige Ports ab. Öffentliche Exploit-Skripte verwenden häufig öffentliche HTTPS-Payload-URLs, die diese Einschränkung umgehen. Dieses Lab tut das nicht.
Um die Reproduktion vollständig lokal zu halten, installiert das Seed-Skript einen kleinen, rein lokalen MU-Plugin-Helfer, der:
payload und payload.local zulässt80 und 9100 zulässtDieser Helfer modifiziert nicht den Breeze-Quellcode. Sowohl der verwundbare als auch der gepatchte Dienst verwenden echte Breeze-Plugin-Versionen, die über WP-CLI installiert wurden.
Der Helfer dient ausschließlich dazu, das Docker-Lab deterministisch und rein lokal zu machen.
Dieses Repository ist ausschließlich für lokale Sicherheitsforschung und Demonstrationszwecke im Portfolio bestimmt.
Schutzvorkehrungen:
localhost und Docker-Netzwerkdienstencmd=-Webshell-VerhaltenDer PoC-Payload gibt harmlose PHP-Laufzeitinformationen aus:
CVE-2026-3844_LEAST_HARM_PHP_EXEC_PROOF_<nonce>
php_sapi=apache2handler
user=www-data
uid=33
pid=<process id>
host=<container hostname>
Dies belegt den Kontext der Codeausführung, ohne Shell-Befehle zu starten.
requestsPython-Abhängigkeit installieren:
python3 -m venv .venv
source .venv/bin/activate
pip install -r poc/requirements.txt
requirements.txt sollte Folgendes enthalten:
requests
Lab erstellen und starten:
docker compose down -v --remove-orphans
docker compose up -d --build
Dienststatus prüfen:
docker compose ps
Erwartete Dienste:
vuln healthy http://127.0.0.1:8081
patched healthy http://127.0.0.1:8082
payload running http://127.0.0.1:9100
vuln_db healthy
patched_db healthy
Seed-Logs prüfen:
docker compose logs --tail=120 vuln
docker compose logs --tail=120 patched
Erwartete Log-Zeilen:
[seed] WordPress ready at http://localhost:8081 with Breeze 2.4.4
[seed] WordPress ready at http://localhost:8082 with Breeze 2.4.5
WordPress-Installation prüfen:
docker compose exec vuln wp core is-installed --allow-root --path=/var/www/html
docker compose exec patched wp core is-installed --allow-root --path=/var/www/html
Breeze-Versionen prüfen: