CVE-2026-73847 — Assistente AI emlog CSRF → Esecuzione SQL → Compromissione Admin

PoC per la mancata protezione CSRF sull'endpoint execute_tool dell'Assistente AI di emlog pro, che consente a un attaccante di cavalcare la sessione autenticata di un admin per eseguire SQL arbitrario sul database del sito — inclusa la completa compromissione dell'account admin.

Causa principale

Il pannello di amministrazione di emlog pro include un assistente AI che può eseguire SQL per conto dell'amministratore tramite POST /admin/ai.php?action=execute_tool. Diversi problemi si accumulano su questo unico endpoint:

1. Nessun token CSRF. Ogni altro file di azione distruttiva in admin/ chiama prima LoginAuth::checkToken() (ad es. admin/media.php:140). admin/ai.php non lo fa mai.
2. L'autenticazione si basa solo sul cookie di sessione (admin/ai.php:152, User::isAdmin()) — nessun controllo Origin/Referer.
3. Il blocco di conferma scrittura è una stringa pubblica hardcoded. include/service/ai.php:594: if (trim($confirm_code) !== 'confirm'). Qualsiasi richiesta falsificata invia semplicemente confirm_code=confirm.
4. La SQL in sola lettura non richiede alcuna conferma (include/service/ai.php:578,589) — una semplice richiesta autenticata può fare SELECT su qualsiasi tabella.
5. Solo la tabella blog è protetta in scrittura () — e tutte le altre tabelle sono completamente scrivibili.

Combinati insieme: una singola richiesta falsificata dal browser di un amministratore legge ogni tabella (incluse le hash delle password) e scrive su ogni tabella tranne blog, compresa la sovrascrittura diretta di user.password.

PoC

Parte 1 — catena di impatto grezza (poc_raw_impact.sh)

Isola la primitiva di bypass SQL/autenticazione dalla questione della consegna CSRF. Eseguilo contro un'istanza locale che controlli:

./poc_raw_impact.sh http://TARGET admin '<adminpass>'

Questo script accede come admin, scarica le hash delle password tramite l'elusione con alias di colonna, sovrascrive direttamente la password dell'admin tramite la tabella user, poi accede di nuovo con la password scelta dall'attaccante da un nuovo cookie jar — dimostrando la completa compromissione dell'account non appena una richiesta autenticata raggiunge l'endpoint.

Parte 2 — consegna CSRF cross-site reale (poc_csrf.html)

Risolve la questione SameSite con un browser reale invece di darla per scontata. Servi poc_csrf.html da un'origine qualsiasi distinta dal target (un IP diverso è sufficiente — Chrome tratta IP letterali distinti come siti separati) e fai aprire la pagina a un admin autenticato entro circa due minuti dall'accesso:

python3 -m http.server 8888
# then point poc_csrf.html's form action at your target and get it opened

Il modulo si invia automaticamente al caricamento, inviando una chiamata falsificata query_database in POST cross-site con confirm_code=confirm.

Verificato dal vivo: la POST cross-site falsificata trasportava il cookie di autenticazione reale dell'admin (sec-fetch-site: cross-site, cookie incluso), restituiva 200 {"code":0,"msg":"ok",...}, e la riga iniettata è stata confermata presente tramite una successiva lettura autenticata. Ripetendo la richiesta identica ~48 minuti dopo contro lo stesso cookie jar, ormai invecchiato, la richiesta è fallita — nessun cookie è stato incluso e il server ha restituito un redirect non autenticato, confermando che la finestra Lax+POST di circa due minuti è il vincolo reale (riflesso in AC:H).

Impatto

• Lettura completa del database: ogni tabella/colonna, incluse le hash delle password e qualsiasi segreto in emlog_options (credenziali SMTP, chiavi API, ecc.).
• Scrittura completa del database su ogni tabella tranne blog, inclusa user — sovrascrittura di ruolo/password/email, dimostrata end-to-end come compromissione dell'account.
• Limitato agli account con role=admin; writer/editor sono bloccati da User::checkRolePermission(). Non è un'escalation di privilegi da un ruolo inferiore — trasforma un singolo clic su un link dannoso da parte di un admin autenticato in una compromissione completa e silenziosa del sito.

Fix

Aggiungi LoginAuth::checkToken() a execute_tool, imposta SameSite=Strict sul cookie di autenticazione e sostituisci la stringa statica confirm_code con un token reale per sessione, monouso. Dettagli completi sulla remediation nell'advisory.

Cronologia della divulgazione

• 2026-07-31 — Segnalato tramite le GitHub Security Advisories secondo la SECURITY.md di emlog.
• 2026-08-01 — Il maintainer ha pubblicato l'advisory e richiesto un CVE.
• 2026-08-16 — CVE-2026-73847 assegnato da GitHub (CNA).

Nota sui crediti: GitHub in qualità di CNA ha pubblicato il record CVE senza una voce credits, nonostante la GHSA stessa accrediti e accetti il segnalatore. Una richiesta di correzione è stata inviata a [email protected] il 2026-08-16; questo README verrà aggiornato se il record verrà corretto.

Disclaimer

Pubblicato dopo che l'advisory era pubblico e un CVE era stato assegnato, per uso difensivo/educativo. Non eseguirlo contro un'istanza emlog che non possiedi o per la quale non sei esplicitamente autorizzato a fare test.