WordPress: una falla nel processo di aggiornamento è sfruttata per eseguire codice sui server, avverte la CISA

Il 3 novembre 2026 la CISA ha aggiunto al suo catalogo delle vulnerabilità sfruttate attivamente CVE-2026-119977, una race condition negli aggiornamenti del core di WordPress che consente a un attaccante non autenticato di eseguire codice sul server durante l’aggiornamento. WordPress l’ha corretta nella versione 7.1.4, rilasciata il 28 ottobre; sono interessate le versioni da 4.7 a 7.1.3.

Cosa è successo

Il 3 novembre 2026 l’agenzia statunitense CISA ha inserito la falla CVE-2026-119977 del core di WordPress nel suo catalogo KEV, confermando che viene usata in attacchi. Le agenzie federali hanno tempo fino al 6 novembre per correggerla e devono anche svolgere un’analisi forense. WordPress aveva risolto il problema nella versione 7.1.4, uscita il 28 ottobre insieme ad altre undici correzioni di sicurezza, descrivendolo come una debolezza del processo di aggiornamento che può portare all’esecuzione di codice remoto durante la finestra di aggiornamento.

Come entrano gli attaccanti

Secondo la scheda CVE, pubblicata da Wordfence, gli aggiornamenti completi del core usano percorsi temporanei prevedibili e raggiungibili dal web. Un attaccante che vince la corsa (una falla di tipo time-of-check to time-of-use, valutata 8,1 in CVSS 3.1) può eseguire codice sul server senza alcun account mentre l’aggiornamento è in corso. Sono vulnerabili tutti i rami da 4.7.0 a 7.1.3. L’attacco è complesso ma reale: secondo BleepingComputer, Wordfence ha bloccato 13.095 tentativi in 24 ore.

Cosa fare ora

  1. Verificate la versione di ogni sito: wp core version con WP-CLI, oppure Bacheca > Aggiornamenti.
  2. Aggiornate a 7.1.4 (wp core update). Per i rami più vecchi WordPress indica che pubblica backport fino alla 4.7: installate l’ultima versione del vostro ramo e pianificate il passaggio alla 7.1.
  3. Per precauzione, bloccate l’accesso web alla directory wp-content/upgrade/ (location ^~ /wp-content/upgrade/ { deny all; } su Nginx, Require all denied su Apache), che non serve a nessun visitatore.
  4. Cercate tracce: eseguite wp core verify-checksums, cercate file PHP in wp-content/upgrade/, account amministratore sconosciuti e file modificati di recente, e controllate i log web intorno agli ultimi aggiornamenti.

Il nostro parere

Qui il punto debole era lo stesso processo di aggiornamento: non basta aggiornare, bisogna proteggere anche il momento in cui l’aggiornamento si installa. Sui siti aziendali servono aggiornamenti controllati, directory di lavoro chiuse al web e un controllo di integrità dei file dopo ogni aggiornamento.

Fonti

Come scegliamo, verifichiamo e scriviamo le nostre analisi →

Il vostro server è esposto? Fate un test gratuito — solo informazioni pubbliche, senza intrusione:

Verificare un server Verificare un sito

Temi che i tuoi server siano esposti? Il nostro team verifica, aggiorna e monitora infrastrutture Linux e cloud 24/7.

Parla con un esperto I nostri servizi di gestione server →