La backdoor di WordPress usa otto punti di ripristino per ricostituirsi dopo la bonifica

Una backdoor di WordPress documentata di recente è in grado di ricostituirsi anche dopo che i difensori ne hanno eliminato i file visibili, grazie a copie ridondanti distribuite tra filesystem, database e, sui server compatibili, memoria condivisa.

Il malware è stato denominato SC per via dei marcatori SC_ trovati nei contenuti iniettati. Sucuri lo descrive come una rete mesh «autoriparante», controllata tramite blockchain. Il ricercatore Gabriel Barbosa ha segnalato che il payload occupa almeno otto posizioni e che i componenti sopravvissuti possono ripristinare le parti dell’infezione eliminate.

Il report su SC è stato pubblicato insieme a informazioni sullo sfruttamento di una vulnerabilità distinta nel plugin wpForo Forum. Gli elementi disponibili non collegano la vulnerabilità alla distribuzione o al funzionamento di SC. I due problemi di sicurezza vanno considerati separatamente.

Otto componenti formano un sistema circolare di persistenza

La resilienza di SC dipende da più percorsi di ripristino, non da un unico file nascosto. Eliminare il plugin visibile può servire a poco se restano disponibili un loader, una copia nel database, un archivio di ripristino o un segmento di memoria condivisa.

Sucuri ha individuato otto componenti principali:

1. .user.ini imposta la direttiva PHP auto_prepend_file, facendo eseguire un loader prima delle richieste PHP all’interno dell’albero di directory interessato.

2. wp-content/c1b12371.php carica un file nascosto, il cui nome inizia con un punto, se questo si trova nella stessa posizione.

3. wp-content/.c1b12371.php funge da loader di primo stadio. Cerca il plugin contraffatto e può ricrearlo nella directory mu-plugins a partire da tre fonti: una copia del plugin standard, uno stub codificato nella directory della cache oppure un pacchetto ZIP di ripristino con un nome esadecimale casuale.

4. wp-content/db.php sfrutta il meccanismo dei drop-in del database caricati automaticamente da WordPress. Contiene il payload della backdoor in forma compressa e codificata in Base64 e ridistribuisce il plugin se il file previsto manca o è più piccolo di una soglia definita.

5. wp-content/advanced-cache.php viene eseguito prima dei plugin ordinari quando la cache è attiva. Può ricostruire il malware da cinque posizioni: il plugin obbligatorio, una copia del plugin standard, codice PHP conservato nella memoria condivisa System V, un pacchetto ZIP oppure il database. Quindi aggancia plugins_loaded e include il plugin ripristinato.

6. wp-content/themes/khorshidi/functions.php garantisce la persistenza a livello di tema. Secondo Sucuri, contiene la stessa backdoor e riscrive il plugin ogni volta che questo è assente.

7. wp-content/mu-plugins/hyper-engine-kit.php è il malware installato come plugin obbligatorio, una categoria che WordPress carica automaticamente.

8. wp-content/plugins/hyper-engine-kit/hyper-engine-kit.php fornisce un’altra copia dello stesso payload nella directory standard dei plugin.

La backdoor rende meno riconoscibili i nomi delle funzioni e usa un decodificatore basato su un cifrario a sostituzione per ostacolare l’analisi del codice. Si nasconde inoltre nella schermata dei plugin dell’amministrazione di WordPress e dai controlli degli aggiornamenti.

Questa architettura rende inaffidabile l’eliminazione dei singoli componenti. Un file che sembra secondario potrebbe essere proprio quello usato per ricostruire tutto il resto al ciclo di esecuzione successivo.

La memoria condivisa estende la persistenza oltre i file e i record SQL

Sui server che supportano la memoria condivisa System V, SC scrive codice PHP in un segmento identificato da una chiave numerica fissa. Il report non specifica il valore della chiave.

Poiché il segmento risiede nella RAM, può restare disponibile anche dopo la bonifica dei file del sito e dei record del database. Il drop-in malevolo advanced-cache.php può recuperare il codice PHP dal segmento e usarlo per ricreare il plugin.

Gli ambienti di hosting condiviso possono rendere più difficili le verifiche e la rimozione. Secondo Sucuri, il segmento di memoria può appartenere a un account diverso e quindi non rientrare nelle normali possibilità di amministrazione del titolare del sito compromesso.

L’infezione registra anche hook cron di WordPress, tra cui nomi casuali e un hook di recupero noto. Il materiale fornito non specifica i nomi degli hook. Un processo cron di sistema esegue il file cron di WordPress, consentendo la ridistribuzione programmata senza dipendere dal traffico dei visitatori.

File, contenuti del database, archivi di ripristino, attività pianificate e memoria condivisa operano quindi come parti di un unico meccanismo di recupero. Limitarsi a ripulire la directory dei plugin di WordPress lascia intatte diverse possibili fonti di ricostruzione.

Il controllo basato su Ethereum consente ulteriori compromissioni

Sucuri descrive SC come una backdoor controllata tramite blockchain, che comunica con l’infrastruttura di comando e controllo attraverso la blockchain Ethereum. Il report disponibile non include identificativi di wallet Ethereum, indirizzi di comando e controllo o indicatori analoghi relativi all’infrastruttura.

Una volta attivo, il malware può rilevare le caratteristiche del sito compromesso, scaricare altri payload e creare un account amministratore WordPress nascosto. Tra le funzionalità attribuite agli operatori figurano:

• Scaricare JavaScript arbitrario da iniettare nelle pagine del sito.
• Distribuire skimmer o altri malware tramite script iniettati.
• Eseguire codice PHP sul server compromesso.
• Disattivare o eliminare plugin selezionati.
• Ripetere il processo di reinfezione quando i componenti vengono rimossi.

Queste funzionalità espongono a rischi sia il sito sia i suoi visitatori. L’esecuzione di PHP lato server offre all’operatore un ampio controllo sull’installazione di WordPress, mentre l’iniezione di JavaScript arbitrario può inserire codice malevolo nelle pagine visualizzate dagli utenti.

Il report citato non identifica l’autore delle operazioni con SC. Specifica inoltre che il metodo iniziale di distribuzione è sconosciuto. Componenti vulnerabili di WordPress, credenziali deboli, catene di fornitura dei plugin compromesse e funzioni di caricamento non sicure sono elencati solo come possibilità comuni, non come punti di accesso confermati per questo malware.

L’iniezione SQL sfruttata in wpForo è un problema distinto

La vulnerabilità del plugin divulgata nello stesso periodo è CVE-2026-1581, un’iniezione SQL basata sul tempo e sfruttabile senza autenticazione, che interessa wpForo Forum nelle versioni dalla 0 alla 2.4.14, inclusa.

La vulnerabilità è raggiungibile tramite il parametro wpfob. La mancata corretta sanitizzazione dei dati controllati dall’utente, unita a una preparazione insufficiente di una query SQL esistente, consente a un attaccante non autenticato di aggiungere query SQL ed estrarre informazioni sensibili dal database.

La scheda del programma CVE pubblicata da Wordfence indica tomdever come fornitore e attribuisce la scoperta della vulnerabilità a Youssef Elouaer. La scheda è stata pubblicata il 19 febbraio 2026 e aggiornata l’8 aprile 2026.

CVE-2026-1581 è classificata HIGH, con un punteggio CVSS 3.1 di 7.5 e il seguente vettore:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

Il vettore descrive una vulnerabilità sfruttabile da remoto, con bassa complessità di attacco, senza privilegi richiesti né interazione da parte dell’utente. L’impatto sulla riservatezza è valutato alto; non sono indicati impatti sull’integrità o sulla disponibilità. La vulnerabilità è classificata come CWE-89, neutralizzazione impropria di elementi usati in un comando SQL.

La telemetria di Previdian ha registrato meno di 20 tentativi di sfruttamento dal 3 luglio 2026. L’attività proveniva da cinque indirizzi IP univoci degli attaccanti, geolocalizzati in Bulgaria, Svizzera, Francia, Stati Uniti e Yemen. Gli indirizzi specifici non sono stati resi noti.

Il report non identifica gli autori di quei tentativi né stabilisce un rapporto tra CVE-2026-1581 e la backdoor SC.

La risposta agli incidenti deve includere tutte le fonti di ripristino

In caso di sospetta compromissione da parte di SC, eliminare hyper-engine-kit.php o uno dei loader non basta a dimostrare che l’infezione sia stata eradicata. Chi interviene deve esaminare tutti e otto i percorsi dei componenti segnalati e le ulteriori fonti di ripristino a cui fanno riferimento.

La verifica dovrebbe includere:

• Le directory dei plugin standard e di quelli obbligatori.
• I drop-in db.php e advanced-cache.php.
• Il file functions.php del tema interessato.
• .user.ini e la relativa impostazione auto_prepend_file.
• I contenuti della cache e i pacchetti ZIP di ripristino con nomi casuali.
• I dati malevoli memorizzati nel database di WordPress.
• Le attività cron di WordPress e di sistema.
• I segmenti di memoria condivisa System V, sui server che li supportano.

Il report disponibile non fornisce una procedura di rimozione di SC convalidata, la chiave numerica della memoria condivisa, l’elenco completo dei nomi degli hook cron né indicatori specifici dell’infrastruttura di comando e controllo. Gli amministratori dovrebbero quindi evitare di dichiarare pulito un sito solo perché il plugin visibile non compare più.

Per CVE-2026-1581, gli operatori dovrebbero verificare se un’installazione WordPress utilizza wpForo Forum 2.4.14 o versioni precedenti. Le schede della vulnerabilità fornite non indicano una versione corretta o una soluzione alternativa, quindi non consentono di indicare una release specifica come rimedio. Gli amministratori dovrebbero consultare le indicazioni aggiornate del fornitore e verificare le attività web e del database per individuare richieste sospette contenenti wpfob.

I due incidenti richiedono indagini diverse. SC impone una ricerca estesa dei meccanismi di persistenza nei diversi livelli di archiviazione ed esecuzione; CVE-2026-1581 richiede invece di valutare l’esposizione del plugin e indagare su eventuali estrazioni di dati dal database. Confondere i due casi potrebbe indirizzare i difensori verso un punto di accesso o una strategia di bonifica sbagliati.