Skip to content
KitploitKITPLOIT
StrumentiBlog
Log in
Invia
StrumentiBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

FeedContattoPrivacy© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
CVE-2026-3844-Lab — Laboratorio Docker locale per riprodurre CVE-2026-3844, un upload arbitrario di file non autenticato che porta a RCE nel plugin WordPress Breeze Cache. Confronta la versione vulnerabile 2.4.4 con la 2.4.5 corretta utilizzando servizi isolati e una PoC a danno minimo. | Kitploit
Strumenti/GitHubGitHub/rootdirective-sec/cve-2026-3844-lab
Analisi delle VulnerabilitàExploitSfruttamento di Applicazioni WebCTFApprendimento e FormazioneLab e Pratica
GitHubrootdirective-sec/cve-2026-3844-lab

CVE-2026-3844-Lab

Laboratorio Docker locale per riprodurre CVE-2026-3844, un upload arbitrario di file non autenticato che porta a RCE nel plugin WordPress Breeze Cache. Confronta la versione vulnerabile 2.4.4 con la 2.4.5 corretta utilizzando servizi isolati e una PoC a danno minimo.

Vedi Repository
1184 mesi faNon ancora revisionato

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →
Condividi

CVE-2026-3844 — Lab RCE per upload arbitrario di file non autenticato in Breeze Cache

Lab Docker solo locale per riprodurre e confrontare il comportamento della CVE-2026-3844 nel plugin WordPress Breeze Cache.

Questo repository dimostra il comportamento vulnerabile in Breeze Cache 2.4.4 e lo confronta con il comportamento corretto in Breeze Cache 2.4.5. Il lab utilizza due servizi WordPress isolati, uno vulnerabile e uno corretto, oltre a un server payload locale all'interno della rete Docker.

La prova di concetto è intenzionalmente a impatto minimo: non usa una webshell, non espone un parametro di comando, non avvia una reverse shell e non richiede la lettura di file dall'interno del container. La prova si basa sul comportamento HTTP osservabile dall'host.


Sommario Esecutivo

La CVE-2026-3844 colpisce il plugin Breeze Cache per WordPress fino alla versione 2.4.4 inclusa. Il percorso di codice vulnerabile è legato alla funzionalità di caching locale dei Gravatar del plugin, in particolare al flusso di fetch_gravatar_from_remote().

Quando l'opzione Breeze Host Files Locally - Gravatars è abilitata, le versioni vulnerabili possono recuperare un file remoto controllato dall'attaccante e salvarlo in una directory cache pubblicamente accessibile via web. Se il file recuperato è PHP, il file può essere eseguito dal web server quando viene richiesto via HTTP.

Questo lab riproduce localmente questo comportamento:

  • servizio vuln: WordPress + Breeze Cache 2.4.4
  • servizio patched: WordPress + Breeze Cache 2.4.5
  • servizio payload: server payload locale solo Docker
  • PoC: trigger basato su commento non autenticato che utilizza una stringa srcset controllata

Il risultato atteso è:

  • http://127.0.0.1:8081 / Breeze 2.4.4 → la prova PHP viene memorizzata nella cache ed eseguita
  • http://127.0.0.1:8082 / Breeze 2.4.5 → la prova PHP non viene memorizzata nella cache, letta né eseguita

Struttura del Repository

.
├── 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

Architettura del Lab

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

I container WordPress recuperano il payload tramite l'URL della rete Docker:

http://payload:9100/<payload-file>.php

L'host verifica il risultato tramite normali richieste HTTP ai servizi WordPress.


Componente Interessato

  • Prodotto: plugin Breeze Cache per WordPress
  • Versione vulnerabile in questo lab: 2.4.4
  • Versione corretta in questo lab: 2.4.5
  • Funzione vulnerabile: fetch_gravatar_from_remote()
  • File pertinente: inc/class-breeze-cache-cronjobs.php
  • Precondizione richiesta: breeze-store-gravatars-locally deve essere abilitata

Il comportamento vulnerabile è raggiungibile solo quando la cache locale dei Gravatar è abilitata. Questa opzione è disabilitata per impostazione predefinita nelle installazioni tipiche, ma questo lab la abilita intenzionalmente per riprodurre il percorso di codice vulnerabile.


Sintesi della Causa Principale

In Breeze Cache 2.4.4, il flusso di localizzazione dei Gravatar può estrarre un URL remoto dall'HTML relativo agli avatar e passare quell'URL a fetch_gravatar_from_remote().

La versione vulnerabile non applica una validazione sufficiente al file remoto:

  • nessuna validazione rigorosa dell'host affidabile per le sorgenti Gravatar
  • nessuna allowlist affidabile delle estensioni di file prima del salvataggio
  • nessuna validazione MIME/contenuto prima di inserire il file in una directory cache pubblica
  • il file recuperato potrebbe mantenere un'estensione pericolosa come .php

Il file risultante viene salvato in:

/wp-content/cache/breeze-extra/gravatars/

Quando un file PHP viene salvato lì e poi richiesto tramite Apache/PHP, il server lo esegue.

In Breeze Cache 2.4.5, il flusso corretto aggiunge una validazione che impedisce al payload di questo lab di essere memorizzato nella cache come PHP eseguibile. Nella riproduzione locale, lo stesso trigger funziona contro 2.4.4 ma non espone il marcatore di prova contro 2.4.5.


Perché Questo Lab Usa un MU Plugin Helper

Questo lab mantiene intenzionalmente il server payload locale invece di usare un host payload pubblico.

download_url() di WordPress e l'API HTTP di WordPress rifiutano di default alcuni hostname Docker privati e porte non standard. Gli script exploit pubblici usano spesso URL HTTPS pubblici per il payload, che evitano questa restrizione. Questo lab non fa così.

Per mantenere la riproduzione completamente locale, lo script di seed installa un piccolo MU plugin helper solo locale che:

  • consente solo gli hostname payload Docker locali payload e payload.local
  • consente solo le porte del lab 80 e 9100
  • approva automaticamente i commenti del lab
  • disabilita i controlli anti-flood dei commenti per test locali deterministici

Questo helper non modifica il codice sorgente di Breeze. Sia il servizio vulnerabile sia quello corretto usano versioni reali del plugin Breeze installate tramite WP-CLI.

L'helper esiste solo per rendere il lab Docker deterministico e solo locale.


Modello di Sicurezza

Questo repository è destinato esclusivamente a ricerca di sicurezza locale e dimostrazioni per portfolio.

Vincoli di sicurezza:

  • gira solo su localhost e servizi di rete Docker
  • nessun server di callback esterno
  • nessun target di exploit pubblico
  • nessuna reverse shell
  • nessuna shell interattiva
  • nessun comportamento webshell cmd=
  • nessun segreto o credenziale reale
  • nessuna lettura di file dal container per la prova
  • la prova viene osservata tramite il comportamento delle risposte HTTP

Il payload del PoC stampa informazioni benigne sull'ambiente runtime di PHP:

CVE-2026-3844_LEAST_HARM_PHP_EXEC_PROOF_<nonce>
php_sapi=apache2handler
user=www-data
uid=33
pid=<process id>
host=<container hostname>

Questo dimostra il contesto di esecuzione del codice senza avviare comandi di shell.


Requisiti

  • Docker Desktop oppure Docker Engine
  • Docker Compose v2
  • Python 3.9+
  • Pacchetto Python: requests

Installa la dipendenza Python:

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

requirements.txt deve contenere:

requests

Avvio Rapido

Compila e avvia il lab:

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

Controlla lo stato dei servizi:

docker compose ps

Servizi attesi:

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

Controlla i log di seed:

docker compose logs --tail=120 vuln
docker compose logs --tail=120 patched

Righe di log attese:

[seed] WordPress ready at http://localhost:8081 with Breeze 2.4.4
[seed] WordPress ready at http://localhost:8082 with Breeze 2.4.5

Verifica che il Lab sia Pronto

Controlla l'installazione di WordPress:

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

Controlla le versioni di Breeze:

Scarica lo strumento