Cosa fa davvero wp2shell

Quando Adam Kues di Assetnote ha inviato una richiesta costruita ad arte a una normale installazione WordPress, il server ha eseguito il suo codice. Nessun account, nessuna password, nessun plugin, nessuna impostazione insolita. I ricercatori hanno chiamato la catena wp2shell, WordPress le ha assegnato CVE-2026-63030 ed entrambe le parti l'hanno giudicata critica.

L'exploit concatena due debolezze nella rotta batch della REST API: una confusione di instradamento che permette a un chiamante non autenticato di raggiungere percorsi di codice che dovrebbero essere protetti, e una SQL injection raggiungibile attraverso di essa. Concatenate, trasformano una richiesta HTTP anonima in esecuzione di codice, l'esito più grave che una falla web possa avere.

Perché la patch automatica non è il traguardo

WordPress ha rilasciato 6.9.5 e 7.0.2 il 17 luglio 2026 e, vista la gravità, ha forzato gli aggiornamenti sui siti colpiti invece di attendere un clic del proprietario. È la scelta giusta e la maggior parte dei siti ora è chiusa. Nasconde però la domanda più difficile.

Una falla senza autenticazione significa che chiunque sulla rete poteva usarla prima della tua patch, e installare la correzione non annulla tutto questo. Se il tuo sito era raggiungibile e non aggiornato durante la finestra di esposizione, l'aggiornamento ha tolto la porta ma non ciò che era già passato: un utente amministratore inserito, un'attività pianificata, una webshell nella cartella dei caricamenti.

Perché quasi ogni proprietario è coinvolto

Questo viveva nel core, il software che ogni sito WordPress esegue, quindi l'esposizione non dipendeva da un plugin o da un tema di nicchia. WordPress muove quasi il 40 per cento del web, ed è per questo che una singola falla del core di questa classe è un evento di massa e non un caso isolato.

Le versioni dalla 6.9.0 alla 6.9.4 e dalla 7.0.0 alla 7.0.1 erano vulnerabili a wp2shell. Il secondo bug, una SQL injection nel parametro author__not_in di WP_Query con CVSS 9.1, risale alla 6.8, così un sito che ha saltato gli aggiornamenti per qualche mese portava la più ampia delle due finestre di esposizione.

In cosa lo trasformano le regole UE

Per un'azienda europea la falla non è solo tecnica. Se dietro quel sito ci sono dati personali, il GDPR ti concede 72 ore per notificare la tua autorità di controllo appena vieni a conoscenza di una violazione, e 'non possiamo escluderlo' è più vicino a quella conoscenza che alla tranquillità.

Per i soggetti essenziali e importanti sotto NIS2, un incidente di questa gravità fa scattare un proprio orologio di preallarme e notifica, e le autorità chiedono sempre più prove di rilevamento, non solo un registro delle patch. Un aggiornamento automatico forzato è una difesa che non hai scelto; se poi hai verificato l'eventuale compromissione è ciò che resta nel tuo registro.

Il controllo che va fatto ora

Conferma che il sito sia sulla 6.9.5 o 7.0.2, poi tratta la finestra di esposizione come il lavoro vero. Rivedi gli account amministratore e le password applicative create a luglio, ispeziona le attività pianificate e i file PHP modificati di recente, ed estrai i log del server web in cerca di richieste POST insolite verso la REST API intorno alla data di divulgazione.

Se usi WordPress gestito, chiedi al tuo hosting per iscritto quando è arrivata la patch e se ha visto tentativi di sfruttamento contro il tuo sito. La risposta onesta a 'siamo stati colpiti' arriva raramente subito, ma i proprietari che chiedono questa settimana sono quelli che il prossimo trimestre non dovranno spiegare una violazione silenziosa.

Da leggere ora: Un edificio inutilizzabile costa più di un riscatto  |  La vostra sandbox colpita un mese prima dell'avviso