WordPress, falla RCE in All-in-One WP Migration: esposti circa 3,2 milioni di siti

Una vulnerabilità ad alta gravità nel plugin All-in-One WP Migration and Backup può essere sfruttata per arrivare all’esecuzione di codice da remoto su un sito WordPress. Il problema è identificato come CVE-2026-19949 e interessa tutte le versioni del plugin fino alla 7.109 inclusa.

La correzione è disponibile nella versione 7.110, rilasciata il 20 agosto. Al 3 settembre 2026, tuttavia, solo il 35% delle oltre 5 milioni di installazioni attive risultava aggiornato. La stima è quindi di circa 3,2 milioni di siti ancora esposti.

La falla colpisce la procedura di ripristino degli archivi .wpress e nasce da una SQL injection second-order. Lo sfruttamento combina input memorizzati nel database, trackback di WordPress, commenti accessibili tramite REST API e un archivio di backup costruito per installare codice malevolo.

Versioni vulnerabili e gravità di CVE-2026-19949

Il perimetro delle installazioni interessate è definito con precisione:

• Prodotto: All-in-One WP Migration and Backup per WordPress;
• Versioni vulnerabili: fino alla 7.109 inclusa;
• Versione corretta: 7.110;
• Componente coinvolto: funzione di importazione e ripristino degli archivi .wpress.

La scheda NVD del NIST assegna alla vulnerabilità un punteggio CVSS v3 di 8.8, con vettore:

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

La classificazione è CWE-89, relativa alla neutralizzazione inadeguata di elementi speciali inseriti in un comando SQL. Il difetto permette di aggiungere query SQL a operazioni già predisposte dal plugin e di recuperare informazioni sensibili dal database.

I valori CVSS indicano impatti elevati su confidenzialità, integrità e disponibilità. L’attacco può essere condotto via rete, presenta una complessità bassa e non richiede interazione da parte di un utente durante l’esecuzione.

Rimane però un’incongruenza nella classificazione. La descrizione della vulnerabilità e l’analisi di Defiant, società che ha segnalato il problema, parlano di uno scenario accessibile a un attaccante non autenticato. Il vettore CVSS contiene invece PR:L, cioè la necessità di privilegi bassi. Non è disponibile un chiarimento definitivo su questa differenza.

Perché è una SQL injection “second-order”

In una SQL injection tradizionale, l’input malevolo raggiunge direttamente una query vulnerabile e viene eseguito nello stesso flusso della richiesta. In questo caso il percorso è più articolato.

L’attaccante inserisce inizialmente dati manipolati che WordPress salva senza trasformarli subito in una query pericolosa. L’input resta nel database e diventa eseguibile solo in un secondo momento, quando il plugin elabora quei dati durante la creazione e il ripristino di un archivio.

Da qui la definizione di second-order SQL injection: il payload viene memorizzato in una prima fase e si attiva successivamente, all’interno di un diverso processo applicativo.

All-in-One WP Migration comprime contenuti, configurazioni e database di un sito in file con estensione .wpress. Durante l’importazione, il plugin deve adattare URL e prefissi delle tabelle al server di destinazione. È proprio questa riscrittura del codice SQL memorizzato a trasformare l’input controllato dall’attaccante in istruzioni eseguibili.

Il problema deriva da un escaping insufficiente di un parametro controllabile dall’esterno e dalla preparazione inadeguata di una query SQL preesistente. L’attacco non coincide quindi con il semplice caricamento di un backup: sfrutta il modo in cui il plugin ricostruisce il database.

Dai trackback alla chiave segreta del plugin

La catena descritta da Defiant comincia con l’invio di due trackback a un articolo WordPress pubblico. Ciascun trackback contiene una barra rovesciata finale e un URL collegato al payload.

Questi valori vengono memorizzati senza eliminare le barre rovesciate e senza bloccare gli URL. Il codice rimane inizialmente inattivo. Per completare la fase di SQL injection è necessario che un amministratore crei un archivio e successivamente lo importi.

Durante il ripristino, il plugin modifica gli URL e i prefissi delle tabelle presenti nel dump SQL. Questa operazione rielabora anche il contenuto inserito nei trackback, trasformandolo in SQL valido.

La query così ottenuta copia in un commento il valore di ai1wm_secret_key, la chiave utilizzata per proteggere le diverse fasi dell’importazione. Il commento viene poi approvato e diventa pubblicamente visibile.

A quel punto l’attaccante può recuperare la chiave senza autenticazione attraverso l’endpoint REST API dei commenti. Il segreto sottratto consente di superare il controllo previsto dalla procedura di importazione, che non utilizza la normale autenticazione amministrativa di WordPress.

La vulnerabilità dipende dunque dall’interazione fra più componenti: trackback del core, database, procedura di ripristino del plugin e REST API dei commenti.

L’archivio .wpress porta all’esecuzione di codice

Dopo avere ottenuto la chiave, l’attaccante può importare un archivio .wpress preparato appositamente. Il file include un must-use plugin malevolo, cioè codice PHP che WordPress carica automaticamente senza richiedere l’attivazione ordinaria prevista per i plugin.

Al successivo caricamento di una pagina, il componente viene eseguito e l’attaccante ottiene la remote code execution. L’esito può essere la compromissione completa dell’installazione WordPress.

Una RCE permette, in base ai privilegi del processo web, di installare webshell, mantenere l’accesso al server e modificare file o configurazioni. Può inoltre esporre i dati conservati nel database, consentire l’alterazione dei contenuti e trasformare il sito compromesso in un punto di appoggio per altre attività.

La catena richiede più passaggi e comprende un’operazione amministrativa di backup e ripristino. Questo non elimina il rischio: il payload può restare memorizzato fino a quando l’amministratore esegue proprio quelle operazioni.

Aggiornamento urgente e verifiche sulle installazioni

La misura correttiva documentata è l’aggiornamento ad All-in-One WP Migration and Backup 7.110. Ogni installazione ferma alla versione 7.109 o precedente deve essere considerata vulnerabile.

Non è stata indicata una mitigazione temporanea ufficiale alternativa. In particolare, non sono disponibili istruzioni documentate per neutralizzare la falla intervenendo soltanto sui trackback, sull’endpoint REST dei commenti o sull’importazione dei file .wpress. Queste modifiche non devono quindi essere considerate sostitutive della patch.

Oltre a verificare la versione installata, gli amministratori dovrebbero controllare eventuali segnali coerenti con la catena descritta:

• trackback anomali contenenti URL inattesi o barre rovesciate finali;
• commenti pubblicati o approvati senza una spiegazione operativa;
• possibile esposizione del valore ai1wm_secret_key;
• importazioni .wpress non riconosciute;
• presenza di must-use plugin sconosciuti;
• file PHP, webshell o modifiche persistenti non attribuibili agli amministratori.

Non sono stati comunicati nomi di file, indirizzi IP, hash o altri indicatori di compromissione specifici. Le verifiche devono quindi concentrarsi sulla cronologia delle importazioni, sui log HTTP, sui contenuti dei commenti e sulla directory riservata ai must-use plugin.

Nessuna informazione su CISA KEV e precedenti del vendor

Non è stato riportato l’inserimento di CVE-2026-19949 nel catalogo Known Exploited Vulnerabilities della CISA. Di conseguenza, non è nota alcuna scadenza federale associata alla vulnerabilità.

L’assenza di uno stato KEV comunicato non dimostra che la falla sia priva di sfruttamento reale; indica soltanto che non è disponibile quella specifica conferma operativa. Non sono stati forniti neppure dati su campagne attive o attacchi osservati su larga scala.

Il nome del produttore non è indicato esplicitamente oltre a quello del prodotto. Non è quindi possibile collegare con affidabilità questo episodio ad altri eventuali precedenti recenti del vendor nel catalogo KEV.

Il dato più immediato resta l’ampiezza dell’esposizione: circa 3,2 milioni di installazioni risultavano ancora vulnerabili al 3 settembre. Per chi gestisce un sito WordPress con questo plugin, la priorità è verificare la versione e installare la 7.110.