Vulnerabilità WordPress sfruttata: cosa devono verificare i gestori
L'agenzia statunitense per la cybersicurezza CISA inserisce CVE-2026-87902 nel catalogo delle vulnerabilità sfruttate attivamente. Per i gestori di WordPress ora non conta solo l'aggiornamento, ma anche la verifica di tracce di un attacco precedente.
Sono interessato? Nel pannello di WordPress, alla voce «Aggiornamenti», verificate la versione core effettivamente installata. Sono interessati i rami di versione da 4.7 a 7.1 privi di patch. Chi ha installato la 7.1.2, la 7.0.6, la 6.9.9, la 6.8.10, la 6.7.9 o la corrispondente versione di sicurezza del proprio ramo più vecchio dispone della correzione pubblicata. I soli aggiornamenti automatici non sono una prova: decisiva è la versione visualizzata.
L'agenzia statunitense per la cybersicurezza CISA ha inserito CVE-2026-87902 il 25 settembre nel suo catalogo delle vulnerabilità note per essere state sfruttate. Questo dimostra che la falla non è descritta solo in teoria, ma viene usata in attacchi reali. A essere interessato è il core di WordPress e quindi, potenzialmente, un numero molto elevato di siti web, compresi quelli di aziende, associazioni e autorità svizzere.
L'avvertimento non significa però che ogni sito WordPress sia già compromesso o che il controllo possa essere preso in qualsiasi configurazione. Determinanti sono la versione installata, il tema attivo e l'ambiente server. Proprio questa distinzione richiede un intervento rapido ma ordinato.
Che cosa conferma davvero la CISA
La CISA elenca la vulnerabilità con la denominazione «WordPress Core Remote File Inclusion Vulnerability». L'inserimento nel Known Exploited Vulnerabilities Catalog, in breve KEV, presuppone indizi solidi di sfruttamento attivo. La voce non fornisce dettagli sulle singole vittime né sulla portata degli attacchi.
Per le agenzie federali civili statunitensi interessate dalla direttiva, la correzione è prevista entro il 28 settembre 2026. Le imprese svizzere non sono soggette a questo termine. Il termine insolitamente breve mostra però quanto alta sia la priorità operativa attribuita dalla CISA.
La differenza più importante sta tra vulnerabilità e incidente: la CISA conferma lo sfruttamento attivo della falla, non l'intrusione in un determinato sito svizzero.
Come un problema di percorso può diventare un attacco
In determinate condizioni, un attaccante non autenticato può indurre la risoluzione dei template di pagina a includere un file PHP locale leggibile al di fuori delle directory del tema attivo. Se sono soddisfatte ulteriori condizioni, da ciò può derivare l'esecuzione di codice sul server.
L'advisory ufficiale indica due presupposti centrali: il tema padre o child attivo ha una directory di primo livello il cui nome inizia con page-, e sul server esiste un file PHP adatto che il server web può leggere. Possono essere interessate, per esempio, determinate strutture di vecchi temi standard e i temi Neve, Hestia e Sydney. L'uso di uno dei temi citati, da solo, non dimostra però né un'installazione immediatamente sfruttabile né un attacco già avvenuto.
Versione corretta, non semplice attivazione degli aggiornamenti automatici
WordPress 7.1.2 chiude la falla. Anche per i rami più vecchi sono stati pubblicati aggiornamenti di sicurezza: 7.0.6, 6.9.9, 6.8.10 e 6.7.9 figurano tra le versioni corrette attuali; altri backport arrivano fino a WordPress 4.7.37. WordPress segnala al contempo che solo l'ultima versione principale è attivamente supportata.
I gestori non dovrebbero quindi limitarsi a controllare se gli aggiornamenti automatici in background sono attivi. Nel pannello deve effettivamente comparire una versione corretta. L'aggiornamento dovrebbe avvenire tramite la normale amministrazione di WordPress, il fornitore di hosting o una fonte ufficiale di WordPress. Prima è prassi standard eseguire un backup affidabile di database e file.
Un aggiornamento chiude la porta, ma non cancella le tracce
Se la falla è già stata sfruttata, l'aggiornamento successivo non annulla automaticamente una modifica. Gli amministratori dovrebbero inoltre verificare se sono stati creati nuovi account utente, modificati diritti di amministratore, caricati file sconosciuti o modificati in modo inatteso plugin e temi. Anche i log del server web, le attività pianificate e le connessioni in uscita possono fornire indizi.
In caso di compromissione confermata, la semplice cancellazione di un file sospetto di solito non basta. Gli aggressori possono lasciare diversi accessi. In tal caso sono più affidabili un ripristino da un backup dimostrabilmente pulito e la chiusura del varco d'ingresso originale. In caso di sospetto, il sito dovrebbe essere isolato e dovrebbe essere coinvolto un supporto specialistico prima che log o altre prove vengano sovrascritti.
Una falla del core, non un singolo plugin
Per la priorizzazione è decisivo che la voce indichi il core di WordPress. Il problema non può quindi essere risolto soltanto disattivando un plugin. Plugin e temi restano comunque parte della verifica: possono influenzare i presupposti dell'attacco, contenere vulnerabilità aggiuntive o essere stati modificati dopo un'intrusione.
Anche un sito visitato di rado non è un obiettivo poco attraente. Scanner automatizzati cercano di continuo sulla rete versioni vulnerabili. I responsabili dovrebbero quindi chiarire chi monitora gli aggiornamenti e chi decide in caso di sospetto, anche se la gestione tecnica è affidata a un'agenzia o a un hoster.
Cinque passi per i gestori
- Controllare nel pannello la versione di WordPress installata.
- Installare la versione di sicurezza corretta del ramo utilizzato.
- Verificare amministratori, plugin, temi e i file modificati più di recente.
- Rinnovare le credenziali di accesso se esiste un sospetto o compaiono account sconosciuti.
- In presenza di tracce di intrusione, isolare il sito e coinvolgere specialisti.
WordPress è utilizzato per negozi online, portali per i membri e siti aziendali. Un sito compromesso può mettere a rischio i dati, dirottare i visitatori o servire da punto di partenza per ulteriori attacchi. Chi ora verifica la versione concreta, aggiorna e poi cerca tracce affronta quindi entrambi i rischi: l'attacco ancora possibile e quello già avvenuto senza essere notato.
Fonti
WordPress: pubblicazione della versione 7.1.2
WordPress/GitHub: advisory di sicurezza su CVE-2026-87902
CISA: CVE-2026-87902 inserita nel catalogo KEV
CISA: catalogo delle vulnerabilità note per essere state sfruttate
