MetInfo CMS sotto attacco RCE: exploit attivo su CVE-2026-29014
Attori minacciosi sfruttano CVE-2026-29014 in MetInfo CMS. RCE non autenticato con CVSS 9.8, spike il 1° maggio 2026 e circa 2.000 istanze esposte.
Contenuto
Uno spike di attacchi contro MetInfo CMS è stato rilevato il 1° maggio 2026: attori minacciosi sfruttano attivamente la vulnerabilità CVE-2026-29014 per eseguire codice da remoto senza autenticazione. Exploit attivi erano già emersi dal 25 aprile 2026 contro honeypot negli Stati Uniti e Singapore, mentre la patch ufficiale è disponibile dal 7 aprile 2026. Per le circa 2.000 istanze esposte su Internet, principalmente in Cina, il rischio di compromissione totale del server è immediato.
- CVE-2026-29014 colpisce MetInfo CMS nelle versioni 7.9, 8.0 e 8.1 con un punteggio CVSS di 9.8, consentendo esecuzione remota di codice PHP senza credenziali.
- La catena di attacco sfrutta il plugin WeChat: il metodo
wxAdminLogin()scrive il parametroFromUserNamein un file di cache PHP tramitecache::put(), dove l’input non viene neutralizzato. - Exploit attivi sono stati rilevati contro honeypot dal 25 aprile 2026, con un’impennata il 1° maggio 2026 concentrata su indirizzi IP di Cina e Hong Kong.
- Circa 2.000 istanze di MetInfo CMS risultano esposte su Internet, principalmente in Cina; la patch ufficiale è disponibile dal 7 aprile 2026.
Come funziona il payload: dalla cache WeChat all’esecuzione di codice
La vulnerabilità risiede nel file /app/system/weixin/include/class/weixinreply.class.php, all’interno del metodo wxAdminLogin(). Questa funzione riceve il parametro utente FromUserName e lo persiste su disco tramite la primitiva cache::put(), generando un file PHP il cui contenuto usa l’interpolazione con doppie virgolette: $cache="{$data}";.
Il dato non viene sanificato prima della scrittura. Un attaccante remoto può quindi inserire nel parametro una sequenza che sfrutta la sintassi {${eval(...)}} di PHP: le graffe innescano la valutazione del codice all’interno della stringa durante l’elaborazione o l’inclusione successiva del file. Il risultato è l’esecuzione arbitraria di comandi sul server con i privilegi del processo web.
Secondo l’analisi tecnica pubblicata da WebSec, il payload viaggia mascherato in un header HTTP personalizzato denominato C e decodificato lato server in Base64. Questa scelta offusca parzialmente il contenuto malevolo durante il transito, rendendo più difficile il rilevamento basato su firme statiche del corpo della richiesta.
"This vulnerability matters because it combines three properties defenders should treat as high priority: no authentication requirement, direct code injection into PHP execution flow, and public exploit availability." — Analisi tecnica WebSec
Il percorso di attacco dal 25 aprile allo spike del 1° maggio
Le prime sonde attive sono state registrate il 25 aprile 2026, quando honeypot posizionati negli Stati Uniti e a Singapore hanno ricevuto richieste malevole. Questa fase iniziale ha confermato che il Proof of Concept disponibile pubblicamente non era rimasto confinato in laboratori di ricerca, ma era già stato integrato in toolchain offensive.
L’intensità è salita bruscamente il 1° maggio 2026. Secondo i dati raccolti da VulnCheck e resi noti da The Hacker News, lo spike ha preso di mira prevalentemente indirizzi IP geograficamente riconducibili a Cina e Hong Kong. Non è noto se questa impennata rappresenti una campagna coordinata da un singolo gruppo o l’azione simultanea di più attori opportunistici.
Il National Vulnerability Database (NVD) descrive la falla come una PHP code injection che consente agli attaccanti di ottenere il controllo completo del server interessato. Il punteggio CVSS di 9.8 riflette la gravità combinata di accesso remoto, assenza di autenticazione e impatto elevato su confidenzialità, integrità e disponibilità.
Il ruolo del Proof of Concept pubblico
La disponibilità di un PoC pubblico ha accelerato la transizione dalla scoperta tecnica all’exploitation di massa. WebSec ha documentato come il payload sfrutti l’interpolazione curly all’interno di un file PHP generato dinamicamente, rendendo l’attacco riproducibile anche da operatori di minaccia con risorse limitate. La presenza di codice già testato riduce il tempo di weaponizzazione a poche ore dalla pubblicazione dell’advisory.
Perché il modulo WeChat diventa un ponte di accesso
La falla non risiede in un componente obsoleto, ma in una funzione di integrazione con WeChat ampiamente utilizzata da chi gestisce siti con audience cinese. L’installazione del plugin ufficiale crea la directory /cache/weixin/, che su server non-Windows funge da destinazione obbligatoria per il file malevolo. Senza questa directory, il percorso di scrittura non è disponibile, rendendo il plugin un prerequisito implicito dell’exploit su tali piattaforme.
Il problema di fondo è architetturale: i dati in arrivo da un’API esterna vengono incapsulati in un file eseguibile dal motore PHP senza un layer di neutralizzazione. Quando una cache scrive codice invece che dati, il confine tra storage ed esecuzione si annulla. In questo caso, l’interpolazione con doppie virgolette trasforma ogni input in una potenziale istruzione.
Cosa fare adesso
Per chi amministra un’istanza MetInfo esposta, le seguenti azioni sono prioritarie e specifiche.
- Aggiornare immediatamente MetInfo CMS alla versione patchata rilasciata il 7 aprile 2026. Le release 7.9, 8.0 e 8.1 sono confermate vulnerabili.
- Disabilitare il plugin WeChat e rimuovere la directory
/cache/weixin/se il modulo non è strettamente necessario. Su server non-Windows questa directory è il prerequisito per la scrittura del file malevolo. - Ispezionare i log del server web alla ricerca di richieste dirette verso
weixinreply.class.phpche presentino l’header HTTPCcon payload in Base64 o sequenze anomale nel parametroFromUserName. - Segmentare l’accesso al pannello di amministrazione e limitare la visibilità di
/app/system/weixin/a origini attendibili, applicando il principio di minimo privilegio anche a livello di rete.
Resta da verificare quante delle circa 2.000 istanze esposte abbiano già applicato la patch e quante siano state effettivamente compromesse. Al momento non sono note l’identità degli attori dietro lo spike del 1° maggio né l’entità concreta dei danni causati.
Domande frequenti
Perché l’attacco richiede il plugin WeChat se la falla è nel codice di MetInfo?
Il metodo vulnerabile appartiene alla classe weixinreply.class.php, caricata dal plugin WeChat. Su server non-Windows la directory /cache/weixin/, creata durante l’installazione del plugin, è necessaria per ospitare il file di cache malevolo. Senza di essa l’exploit non dispone del percorso di scrittura richiesto su tali sistemi.
In cosa differisce questa code injection da una classica SQL injection?
In una SQL injection l’attaccante manipola interrogazioni al database; qui l’input malevolo viene scritto direttamente in un file .php tramite interpolazione di stringhe. La sintassi {${eval(...)}} innesca l’esecuzione immediata del codice PHP all’interno del file di cache, aggirando completamente il livello di persistenza dati.
È possibile mitigare il rischio senza aggiornare MetInfo?
Su server non-Windows la rimozione della directory /cache/weixin/ e la disattivazione del plugin WeChat eliminano il prerequisito per la scrittura del file. Tuttavia, la mitigazione definitiva resta l’installazione della patch ufficiale del 7 aprile 2026, poiché altri vettori potrebbero emergere dalle stesse classi vulnerabili.
La vicenda conferma come funzionalità ausiliarie come l’integrazione con WeChat possano trasformarsi in vettori critici quando l’input utente viene scritto direttamente su file eseguibili. Per i team di sicurezza, la priorità non è solo l’aggiornamento del CMS, ma una revisione sistematica delle logiche di cache che generano file PHP da dati esterni. L’assenza di autenticazione richiesta per l’exploit riduce il margine di manovra: chi gestisce un’istanza esposta deve agire ora.
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.