Admin Menu Editor Pro compromesso: cosa controllare su WordPress

Se hai installato Admin Menu Editor Pro 2.35, tratta il sito WordPress come compromesso. Se hai installato la 2.36, trattalo come potenzialmente compromesso. Lo sviluppatore del plugin ha comunicato che due pacchetti distribuiti il 14 settembre 2026 sono stati alterati dopo una violazione della propria infrastruttura. Aggiornare o tornare a una versione precedente, da solo, non basta a dimostrare che il sito sia pulito: serve controllare file, utenti, opzioni del database, MU plugin e attività pianificate.

Il caso è più serio di una normale vulnerabilità del plugin perché riguarda una compromissione della supply chain: il codice dannoso è arrivato all’interno di un aggiornamento distribuito dal canale ufficiale. Lo sviluppatore continua a indagare e avverte che le indicazioni di pulizia potrebbero non coprire ancora ogni possibile modifica effettuata dall’attaccante.

Versione	Valutazione prudente	Azione
2.34 o precedente	Non risulta compromessa dall’incidente descritto	Verifica comunque origine e integrità del pacchetto
2.35	Da considerare compromessa	Isola, controlla e ripristina
2.36	Da considerare potenzialmente compromessa	Stessi controlli di sicurezza

Admin Menu Editor Pro 2.35 e 2.36: cosa è successo

Nella pagina ufficiale sull’incidente di sicurezza, lo sviluppatore spiega che il pacchetto 2.35 pubblicato il 14 settembre è stato alterato e conteneva codice dannoso. La versione includeva anche un file denominato includes/wp-user-consent.php, descritto come una web shell.

Il team ha poi pubblicato la 2.36 per sostituire il pacchetto compromesso, ma anche quella distribuzione è stata successivamente considerata a rischio. L’ipotesi comunicata dallo sviluppatore è che l’attaccante possa aver avuto accesso molto profondo al server usato per distribuire gli aggiornamenti, fino a un possibile accesso root. Per questo il problema non va trattato come un semplice bug corretto con una nuova release.

Come capire se il tuo sito è coinvolto

Il primo controllo è la cronologia delle versioni. Se il sito ha installato Admin Menu Editor Pro 2.35 o 2.36, anche solo temporaneamente, considera aperto un incidente fino a verifica completata. Non basta guardare la versione attuale: un sito può essere tornato alla 2.34 e conservare comunque file o persistenze create durante la finestra di compromissione.

1. Apri Plugin > Plugin installati e verifica la versione attuale di Admin Menu Editor Pro.
2. Controlla backup, log o cronologia degli aggiornamenti per capire se 2.35 o 2.36 sono state installate dal 14 settembre.
3. Se una delle due versioni è passata dal sito, evita di considerare concluso l’intervento con un semplice downgrade.
4. Conserva log e copie dei file sospetti prima di cancellarli se il sito è aziendale o contiene dati importanti.

Gli indicatori da controllare subito

Lo sviluppatore ha pubblicato diversi indicatori tecnici che possono segnalare la persistenza del codice malevolo. La loro assenza non prova automaticamente che il sito sia pulito, ma la loro presenza richiede un’indagine immediata.

• una directory /wp-content/object-cache con file dal nome esadecimale o comunque non riconducibili al normale sistema di cache;
• opzioni nel database che iniziano con wp_ocache oppure _wp_ocache_;
• utenti nascosti o inattesi nella tabella wp_users, in particolare login che iniziano con wp_ seguiti da caratteri esadecimali;
• MU plugin inattesi con nomi che iniziano con wp- seguiti da caratteri esadecimali;
• un’attività WP-Cron chiamata _wp_cconsent_tick;
• il file includes/wp-user-consent.php all’interno del plugin o copie dello stesso codice in altre posizioni.

Non cancellare automaticamente una cartella o un file solo perché contiene la parola object-cache: diversi plugin di caching usano meccanismi legittimi con nomi simili. Devi confrontare percorso, contenuto, data di modifica e origine con la configurazione reale del sito.

La soluzione più sicura: ripristinare un backup precedente al 14 settembre

Quando disponibile, la strada più prudente indicata dallo sviluppatore è ripristinare un backup sicuramente pulito creato prima del 14 settembre 2026. Il ripristino deve riguardare sia i file sia il database, perché la persistenza descritta nell’incidente può interessare entrambi.

Dopo il restore non limitarti a rimettere online il sito. Cambia le credenziali amministrative, verifica le chiavi di sicurezza, aggiorna plugin e temi da fonti affidabili e controlla i log. Se il sito gestisce e-commerce, utenti registrati o dati personali, valuta la risposta come un vero incidente di sicurezza e coinvolgi hosting o responsabile IT.

Se non hai un backup pulito: cosa fare

Lo sviluppatore propone anche un percorso alternativo per chi non può tornare a un backup precedente. Va letto come procedura di contenimento e pulizia, non come garanzia matematica di bonifica, perché l’indagine è ancora in corso.

1. Rimuovi le versioni 2.35 e 2.36 compromesse e non reinstallarle da vecchi pacchetti salvati localmente.
2. Verifica e rimuovi gli indicatori malevoli indicati dallo sviluppatore, prestando attenzione a non cancellare componenti legittimi della cache.
3. Controlla gli utenti amministratori e rimuovi account sconosciuti solo dopo averne documentato l’origine.
4. Controlla MU plugin, cron e file modificati dal 14 settembre.
5. Ruota tutte le credenziali WordPress, non solo la password dell’amministratore principale.
6. Rigenera i salt di WordPress nel file wp-config.php per invalidare le sessioni attive.
7. Cambia le credenziali di database, FTP/SFTP, pannello hosting e API quando esposte allo stesso ambiente.
8. Esegui una scansione malware e confronta i file core con le copie ufficiali di WordPress.
9. Monitora accessi, modifiche e attività cron dopo la pulizia.

Perché aggiornare o fare downgrade non basta

Una volta eseguito codice con privilegi sufficienti, un attaccante può creare persistenza al di fuori del plugin originale. È lo stesso motivo per cui, dopo una falla sfruttata, la patch chiude il punto d’ingresso ma non elimina automaticamente ciò che è già stato lasciato sul server. Nel recente caso di Elementor Pro vulnerabile abbiamo applicato lo stesso principio: aggiornamento e verifica post-compromissione sono due fasi diverse.

Anche la 2FA su WordPress resta importante, ma non risolve una supply-chain compromise già avvenuta. La 2FA protegge soprattutto le credenziali e gli accessi, mentre qui il codice è potuto arrivare attraverso un pacchetto software considerato legittimo.

Cosa non fare

• Non limitarti a disattivare il plugin. La persistenza può essere altrove.
• Non dare per pulito il sito solo perché ora mostra la 2.34.
• Non cancellare file sospetti senza conservare log e copie se devi ricostruire l’incidente.
• Non reinstallare pacchetti 2.35 o 2.36 da backup locali o repository non verificati.
• Non cambiare soltanto la password WordPress. Considera anche hosting, database, FTP/SFTP, API e salt.
• Non ignorare un sito apparentemente normale. Una web shell può restare silenziosa fino a un utilizzo successivo.

Checklist finale dopo la bonifica

Verifica	Stato da ottenere
Versione 2.35/2.36 rimossa	Completato
File e cartelle sospette	Nessun indicatore noto presente
Utenti amministratori	Solo account autorizzati
MU plugin e WP-Cron	Nessuna voce inattesa
Password e salt	Ruotati
Hosting, DB, FTP/SFTP, API	Credenziali cambiate quando necessario
Scansione malware	Completata
Log dopo il ripristino	Monitorati

Il punto da non perdere è questo: Admin Menu Editor Pro 2.35 va considerato compromesso e la 2.36 potenzialmente compromessa. Se una delle due versioni è passata dal tuo WordPress, la priorità non è soltanto “aggiornare il plugin”, ma verificare l’intero ambiente e, quando possibile, ripartire da un backup certamente precedente all’incidente. Poiché l’indagine del produttore è ancora in corso, ricontrolla la pagina ufficiale prima di chiudere definitivamente il caso.