La catena di vulnerabilità del core di WordPress consente l’esecuzione di codice da remoto senza autenticazione

I ricercatori di sicurezza hanno divulgato una coppia di vulnerabilità nel core di WordPress che possono essere concatenate per eseguire codice senza autenticazione. I problemi interessano le installazioni core, pertanto anche i siti che non eseguono plugin di terze parti potrebbero essere a rischio.

Le vulnerabilità sono identificate come CVE-2026-63030 e CVE-2026-60137. La prima riguarda un’interpretazione errata nella route di elaborazione batch dell’API REST di WordPress, mentre la seconda è un’iniezione SQL che interessa il parametro author__not_in utilizzato da WP_Query. In combinazione, le vulnerabilità consentono a un aggressore di inviare una richiesta anonima che raggiunge la query del database vulnerabile e può potenzialmente portare all’esecuzione di codice da remoto.

Versioni interessate

• WordPress dalla versione 6.8.0 alla 6.8.5: interessato dall’iniezione SQL; risolto nella versione 6.8.6.
• WordPress dalla versione 6.9.0 alla 6.9.4: interessato dall’intera catena d’attacco; risolto nella versione 6.9.5.
• WordPress 7.0.0 e 7.0.1: interessato dall’intera catena; risolto nella versione 7.0.2.
• WordPress 7.1 beta 2 include entrambe le correzioni.

Il ricercatore Adam Kues di Assetnote ha segnalato il problema dell’API REST tramite il programma HackerOne di WordPress. Altri ricercatori hanno segnalato separatamente l’iniezione SQL. Da allora sono stati pubblicati dettagli tecnici e un proof of concept funzionante, aumentando la probabilità che gli aggressori tentino di riprodurre l’exploit.

WordPress classifica come critica la vulnerabilità concatenata, sebbene il relativo punteggio CVE sia 7,5. Alla sola iniezione SQL è stato assegnato un livello di gravità critico. Al 18 luglio non erano state segnalate compromissioni confermate e il problema non risultava incluso nel catalogo delle vulnerabilità sfruttate note di CISA.

Azioni consigliate

Gli amministratori devono verificare la versione installata e aggiornarla il prima possibile a una release corretta, invece di affidarsi agli aggiornamenti automatici. Secondo quanto riferito, il percorso di esecuzione del codice richiede l’assenza di una cache persistente degli oggetti, ma Redis o Memcached non devono essere considerati un’alternativa all’applicazione delle patch.

Fino all’applicazione degli aggiornamenti, le organizzazioni possono valutare di bloccare, tramite un firewall per applicazioni web, l’accesso anonimo a /wp-json/batch/v1 e al percorso equivalente rest_route=/batch/v1. Disabilitare l’accesso non autenticato all’API REST o utilizzare un filtro temporaneo per rifiutare le richieste batch anonime sono ulteriori opzioni, sebbene queste misure possano interrompere integrazioni legittime e non eliminino l’iniezione SQL sottostante.