WPsec.itSicurezza WordPress
Tutti gli articoli
Vulnerabilità5 min di letturaTeam WPsec.it

WordPress Core: tre security release in un mese, cosa verificare adesso

Da wp2shell all'RCE via Ghostscript: WordPress ha corretto tre catene ad alto impatto tra luglio e agosto 2026. Versioni, condizioni reali e checklist.

Condividi
WordPress Core: tre security release in un mese, cosa verificare adesso

Il dato interessante non è il numero di CVE. È la varietà delle condizioni di attacco: REST API, pagina di login, ruoli editoriali e pipeline di elaborazione immagini. In poche settimane sono stati coinvolti livelli diversi dello stesso stack WordPress.

Questo non significa che ogni sito non aggiornato sia stato compromesso. Significa che un inventario vecchio, un job di auto-update fallito o una branch dimenticata possono lasciare aperto un rischio importante senza sintomi visibili.

Le tre correzioni da conoscere

DataRelease principaleProblemaCondizione decisiva
17 luglio 2026WordPress 7.0.2REST batch-route confusion più SQL injection, fino a RCECore 6.9 o 7.0 vulnerabile
6 agosto 2026WordPress 7.0.3XSS riflesso pre-auth su wp-login con possibile escalationInterazione della vittima e condizioni aggiuntive
12 agosto 2026WordPress 7.0.4RCE tramite file PostScript malevoloUtente Author+ con upload, Imagick e Ghostscript

Le versioni nella tabella sono quelle della branch 7.0. WordPress ha pubblicato anche backport sulle branch coinvolte. La scelta corretta non è installare a mano un numero preso da un articolo, ma portare ogni sito all'ultima security release disponibile per la sua branch, o alla release corrente dopo test di compatibilità.

1. wp2shell: quando due difetti diventano una RCE

La release 7.0.2 ha corretto due problemi collegati:

  • CVE-2026-60137, una SQL injection facilitata in WP_Query;
  • CVE-2026-63030, una confusione nella batch route della REST API che, combinata con il primo difetto su WordPress 6.9 e 7.0, può portare a esecuzione di codice remoto.

La distinzione conta. Il secondo advisory non descrive una generica falla presente in qualsiasi vecchia installazione WordPress: indica come vulnerabili alla catena RCE le branch 6.9 fino alla 6.9.4 e 7.0 fino alla 7.0.1. La parte SQL injection coinvolgeva anche la branch 6.8 fino alla 6.8.5.

WordPress.org ha considerato la gravità sufficiente per abilitare aggiornamenti forzati sulle versioni interessate. Ma "forzato" non equivale a "riuscito": permessi filesystem, costanti di configurazione, filtri del provider, spazio disco e job interrotti possono comunque impedire l'allineamento.

2. XSS2Shell: il login è una superficie pubblica

Con WordPress 7.0.3 è stato corretto CVE-2026-64638, un XSS riflesso pre-auth nella schermata di login. L'advisory ufficiale lo classifica High con CVSS 8.9 e precisa che l'escalation a esecuzione di codice richiede social engineering, interazione attiva della vittima e altre condizioni non controllabili interamente dall'attaccante.

Questa precisione evita due errori opposti:

  • liquidare il problema perché "serve un clic";
  • presentarlo come una RCE automatica contro qualsiasi sito.

La schermata di login è raggiungibile prima dell'autenticazione. Se un amministratore viene indotto ad aprire un URL costruito per il proprio dominio, il browser opera nello stesso contesto del sito. Per questo la patch resta urgente anche se il percorso completo non è universale.

Il fix è stato distribuito su più branch fino alla 4.7. Una vecchia major non diventa però una piattaforma consigliabile solo perché ha ricevuto questo singolo backport: WordPress ricorda che la release più recente è quella attivamente supportata.

3. Upload malevolo, Imagick e Ghostscript

Sei giorni dopo è arrivato CVE-2026-65640, corretto in WordPress 7.0.4 e nelle release di sicurezza delle branch precedenti.

Il percorso richiede tre condizioni:

  1. un account con ruolo Author o superiore e capacità di caricare file;
  2. Imagick usato da WordPress per elaborare le immagini;
  3. Ghostscript presente nella pipeline del server.

In questa combinazione, un file PostScript malevolo può arrivare all'esecuzione di codice. L'advisory assegna CVSS 8.8: non è pre-auth, ma un account editoriale compromesso o non fidato può trasformarsi in accesso al server.

Per siti con redazioni, marketplace, membership o molti collaboratori, il controllo dei ruoli diventa quindi parte della risposta. Aggiornare il core chiude il difetto, ma non spiega eventuali upload o attività anomale avvenute prima.

Cosa controllare oggi

1. Versione effettiva, sito per sito

Non usare il pannello centralizzato come unica fonte. Verifica anche dall'installazione, dall'hosting o con WP-CLI. Se gestisci più ambienti, includi produzione, staging pubblici, sottodomini e copie dimenticate.

2. Esito dell'aggiornamento

Controlla che il core non sia rimasto in maintenance mode, che i checksum siano coerenti e che il frontend, il login, l'editor e le funzioni critiche del sito rispondano correttamente.

3. Branch supportata

Una patch retroportata riduce il rischio specifico, ma non rende sostenibile tenere indefinitamente una branch obsoleta. Pianifica l'upgrade della major separatamente, con staging e rollback verificato.

4. Ruoli e capacità di upload

Rivedi gli account Author, Editor e Administrator. Disabilita quelli non più necessari e controlla upload recenti se il server usa Imagick e Ghostscript.

5. Log e integrità

Se il sito è rimasto vulnerabile, cerca richieste anomale alla REST API e alla pagina di login, modifiche inattese ai file, nuovi plugin, utenti amministratori sconosciuti e sessioni fuori profilo. L'assenza di un alert non dimostra l'assenza di compromissione.

Aggiornare non equivale a bonificare

La patch risponde alla domanda "la stessa tecnica può ancora entrare?". Non risponde a "qualcuno è entrato prima della patch?".

Se trovi file modificati, utenti nuovi, plugin inattesi, redirect o attività amministrativa non attribuibile, conserva le evidenze e tratta il caso come incidente. Cancellare subito ciò che sembra strano può distruggere informazioni utili per capire vettore e persistenza.

Fonti

Pubblicato il

Condividi

Scritto dal team WPsec.it

Team WPsec.it

Bonifica malware, hardening, performance e manutenzione WordPress.

Prevenzione e gestione

Dopo l'emergenza, o per non arrivarci: le guide sulla gestione.

Sicurezza, velocità e manutenzione di WordPress sono lo stesso lavoro visto da tre lati. Queste pagine spiegano cosa controllare, con quale priorità e quanto costa farlo fare.

Continua a leggere

Articoli correlati.