Descrizione

Modern Events Calendar Lite registra una famiglia di azioni "load more" non autenticate su admin-ajax.php per le sue skin di elenco eventi (list, grid, masonry, agenda, timeline, tile, custom). Ogni handler legge l'array atts controllato dall'attaccante dalla richiesta, lo passa a un helper chiamato sanitize_deep_array() che — quando chiamato con i suoi argomenti predefiniti — non esegue alcuna sanitizzazione — e poi concatena i valori di atts['include'] (e atts['exclude']) grezzi in un frammento SQL post_id IN (...) eseguito con $wpdb->get_results() e senza $wpdb->prepare().

Poiché i punti di ingresso sono registrati su wp_ajax_nopriv_*, non è richiesta alcuna autenticazione, account, nonce o interazione utente. Un attaccante remoto non autenticato può iniettare SQL arbitrario nella clausola WHERE di una SELECT contro wp_mec_dates e leggere qualsiasi dato nel database WordPress (hash delle password utente, segreti/chiavi di wp_options, dati di altri plugin) tramite tecniche cieche basate sul tempo / booleane / basate sugli errori.

Causa principale

1. Un "sanitizzatore" che non sanitizza nulla sul percorso predefinito

app/libraries/main.php:9607:

Il controllo (is_array($excludes) and !count($excludes)) rende la funzione una completa no-op quando $excludes è l'array vuoto predefinito — ogni valore viene copiato così com'è. L'intento era evidentemente "se esiste una lista di esclusione, salta quelle chiavi"; la logica booleana salta invece tutto ogni volta che non viene fornita alcuna lista di esclusione.

2. Il chiamante non fornisce $excludes

app/skins/list.php:499-501 (load_more()):

sanitize_deep_array($_REQUEST['atts']) viene chiamato con un singolo argomento → $excludes assume il valore predefinito array() → il ramo no-op di cui sopra → $atts è il grezzo, non attendibile $_REQUEST['atts'].

3. Concatenazione grezza nella clausola IN (...)

app/libraries/skins.php:

Gli elementi dell'array vengono passati a implode() direttamente nella stringa SQL senza cast a intero e senza escaping. (absint()/(int) su ogni elemento avrebbe chiuso questa falla.)

4. Esecuzione senza prepared statement

app/libraries/db.php:79:

La stringa completamente costruita viene passata così com'è a $wpdb->get_results().

Flusso del taint (richiesta → sink):

Raggiungibilità

app/skins/list.php:51-52:

La registrazione nopriv rende l'endpoint raggiungibile prima dell'autenticazione. La stessa struttura di load_more() e il query builder condiviso in skins.php sono presenti nelle skin sorelle, ciascuna con la propria azione wp_ajax_nopriv_*, quindi la stessa iniezione è raggiungibile tramite una qualsiasi di:

Nessun nonce viene verificato in load_more(), e l'azione non richiede che alcuno shortcode del plugin sia presente in una pagina: gli handler AJAX vengono registrati incondizionatamente all'init.

Prova di concetto (verificata in laboratorio, MEC Lite 6.5.6, WordPress 6.6.5, MariaDB 10.x)

Tutte le richieste sono non autenticate (nessun cookie, nessun nonce). Il valore iniettato viene inserito in atts[include][]; il payload chiude le due parentesi aperte del gruppo IN ((...) AND (... IN ( e aggiunge un OR <sleep> di livello superiore così che la condizione venga valutata per ogni riga scansionata, poi commenta i )) ORDER BY ... finali:

La query esatta eseguita (catturata da WP_DEBUG_LOG) per un error-canary atts[include][]=0)MEC_SQLI_CANARY era:

— il token letterale MEC_SQLI_CANARY appare testualmente nell'istruzione eseguita, confermando la concatenazione grezza. Il parametro atts[exclude][] (skins.php:803 / 603, NOT IN) è iniettabile allo stesso modo (confermato in laboratorio: atts[exclude][]=0)) OR SLEEP(3)# → ~3.5s). La query e l'iniezione identiche sono state riprodotte su 7.33.0 (build attuale) — stessa canary, stesso comportamento SLEEP.

PoC automatizzato

mec-unauth-sqli-poc.py (incluso) è completamente autonomo e non richiede credenziali: conferma l'iniezione (baseline vs. SLEEP), quindi esegue l'estrazione cieca basata sul tempo di dati arbitrari (predefinito: @@version, utente del database e user_login:user_pass del primo admin). Valida ogni risposta (HTTP 200) e dosa le richieste con --delay + back-off per superare WAF/rate-limiting (es. mod_evasive). Nessun dato viene modificato (contesto SELECT di sola lettura).

Impatto

Accesso in lettura completo, non autenticato e raggiungibile di rete, al database: hash delle password di wp_users, wp_options (auth_key, segreti API, token) e qualsiasi altra tabella. In pratica ciò porta a una completa compromissione del sito (cracking offline degli hash, furto di segreti/sessioni). L'impatto sull'integrità è limitato — l'iniezione viene eseguita in una SELECT tramite $wpdb->get_results(), che non consente query impilate — quindi I:N. SLEEP/BENCHMARK pesanti potrebbero degradare la disponibilità, ma l'impatto primario e dimostrato in modo affidabile è la riservatezza (C:H), che porta a un CVSS 7.5.

File interessati

I numeri di riga sono indicati per 7.33.0 (attuale) con 6.5.6 tra parentesi; il codice è identico in tutto l'arco.

Le skin sorelle (grid, masonry, agenda, timeline, tile, custom) condividono la stessa load_more() + il query builder di skins.php e ciascuna registra un'azione wp_ajax_nopriv_* → stesso bug, molteplici punti di ingresso.

Differenza rispetto alle precedenti CVE di SQL injection di Modern Events Calendar

Questo è un punto di iniezione distinto e precedentemente non segnalato. Ogni SQL injection MEC documentata pubblicamente prende di mira una diversa azione AJAX e un diverso parametro, e tutte sono state corrette in versioni precedenti a questa scoperta (confermata attiva in laboratorio nella 7.33.0):

• Percorso di codice diverso. I precedenti problemi non autenticati si trovano nell'handler per evento singolo mec_load_single_page; questo si trova nella paginazione "load more" della skin (load_more() → MEC_skin::initialize() → costruttore post_id IN (...) in app/libraries/skins.php), raggiunto tramite il ramo predefinito no-op di sanitize_deep_array(). Le patch di mec_load_single_page non toccano skins.php.
• Nessuna precondizione di configurazione. CVE-2021-4458 (id) era sfruttabile solo con l'input slashing di PHP/WordPress disabilitato (uno stato non predefinito) perché quel valore si trova in un contesto tra virgolette. Qui i valori atts[include]/atts[exclude] finiscono in un contesto numerico IN(...) senza virgolette e vengono sfruttati con parentesi + keyword SQL (0)) OR SLEEP(3)#), cosa che wp_magic_quotes() non neutralizza. È quindi sfruttabile su un'installazione WordPress predefinita — confermato in laboratorio su WP 7.0 stock (magic quotes attive).
• Sopravvive a tutte le correzioni precedenti. Confermata attiva su 7.33.0 — quattro anni e una major version dopo l'ultima patch di mec_load_single_page (6.4.0).

Nota su divulgazione / ambito

Modern Events Calendar Lite è stato rimosso da wordpress.org il 2022-05-11 ("Motivo: violazione delle linee guida"), quindi la build wordpress.org è congelata alla 6.5.6. Questo non significa che il plugin sia abbandonato — Webnus ha continuato lo sviluppo fuori piattaforma: la build Lite attuale distribuita da mec.webnus.net è la 7.33.0, e il percorso di codice vulnerabile è identico byte per byte (confermato in laboratorio; la SQLi si attiva in modo identico su 7.33.0). Il bug quindi colpisce ogni release nell'intero arco successivo alla rimozione, non solo la copia congelata di wordpress.org.

Implicazioni di instradamento (l'obiezione "chiuso su wordpress.org" è molto più debole di quanto sembri):

• È un prodotto attuale, distribuito dal vendor e supportato, non codice abbandonato — una divulgazione coordinata a Webnus è il canale primario; distribuiscono attivamente aggiornamenti e dovrebbero correggere.
• MEC Pro (venduto attivamente; 7.x attuale) è costruito su questo stesso codebase 7.x. app/libraries/skins.php, app/libraries/main.php e app/libraries/db.php sono librerie core condivise, quindi Pro è quasi certamente interessato. Questo dovrebbe essere confermato sul sorgente di Pro prima di affermarlo formalmente, ma l'architettura a librerie condivise lo rende molto probabile. Un impatto Pro confermato rende la scoperta inequivocabilmente nell'ambito di Patchstack (un componente venduto pubblicamente) e meritevole di una CVE MITRE/Patchstack indipendentemente dallo stato nella lista wordpress.org.
• Per i consumatori che si basano specificamente sulla presenza nella lista wordpress.org (alcuni criteri di bounty di Wordfence; l'esclusione "componente chiuso" di Patchstack come applicata alla build gratuita Lite), citare l'impatto della 7.33.0 distribuita dal vendor + Pro piuttosto che la 6.5.6 congelata.

Una CVE è giustificata nel merito: SQL injection non autenticata, raggiungibile di rete, con lettura completa del database, in un prodotto attuale distribuito dal vendor con una base di installazioni storica a sei cifre.

Cronologia