> ## Content Index
> Fetch the complete content index at: https://reinaldoferro.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# WordPress CVE-2026-119977: l'aggiornamento che chiude la falla può esporre il sito un'ultima volta
- URL: https://reinaldoferro.com/wordpress-cve-2026-119977-laggiornamento-che-chiude-la-falla-puo-esporre-il-sito-unultima-volta/
- Published: 2026-11-07T10:12:58.000Z
- Updated: 2026-11-07T10:12:58.000Z
- Description: La patch 7.1.4 per la falla WordPress sfruttata attivamente (CVE-2026-119977) viene installata dall'updater vecchio, ancora vulnerabile. Il ricercatore che l'ha trovata consiglia di bloccare wp-content/upgrade prima di aggiornare.
- Author: Reinaldo Ferro
- Tags: WordPress, CVE-2026-119977, Vulnerabilità, CISA KEV, Web Security

## Cosa è successo

Aggiornare WordPress alla versione che corregge CVE-2026-119977 può esporre il sito per l'ultima volta. La falla è nell'aggiornatore del core, ed è già sfruttata attivamente. Secondo Umut Bayram, ricercatore di Picus Security che l'ha segnalata, il pacchetto che installa la correzione viene estratto dal codice *vecchio* già presente sul sito, quindi ancora vulnerabile. Un attaccante che colpisce nel momento giusto può eseguire codice sul server.

Il bug è una race condition di tipo TOCTOU (time-of-check/time-of-use) che interessa WordPress dalla 4.7 alla 7.1.3\. Durante un aggiornamento del core con pacchetto completo, WordPress decomprime una copia della nuova versione in una cartella temporanea sotto `wp-content/upgrade`. La copia include l'installer, che su molti server è raggiungibile via web. Un attaccante senza account che riesca a indovinare il nome della cartella e a raggiungere l'installer prima della cancellazione può arrivare a eseguire codice PHP.

WordPress ha rilasciato la correzione il 28 ottobre 2026 con la versione 7.1.4, più i rilasci di sicurezza per i rami più vecchi. La correzione assegna alla cartella temporanea un nome casuale. L'ultima finestra di rischio riguarda quindi solo l'aggiornamento che porta la patch.

## Perché conta

È una vulnerabilità che si apre proprio mentre l'amministratore fa la cosa giusta, cioè aggiornare. Non serve alcun account, e il codice di un attaccante può girare con i permessi del web server. Da lì si possono leggere e scrivere file del sito live.

La CISA ha inserito la falla nel catalogo KEV il 3 novembre 2026, sulla base di prove di sfruttamento attivo. Non ha però descritto gli attacchi né indicato chi li conduce. Wordfence, che ha assegnato il CVE, ha registrato tentativi di attacco anche per la finestra dell'aggiornamento: secondo la sua analisi, due delle sorgenti più attive hanno controllato piccoli gruppi di siti per circa 14,5 ore, un comportamento coerente con il tentativo di cogliere il momento in cui un sito si aggiorna.

## Contesto

Il meccanismo, in sintesi: il pacchetto completo contiene l'installer di WordPress. Prima della patch, un attaccante poteva usarlo per scrivere un `wp-config.php` nella copia temporanea, che l'aggiornamento poteva poi copiare sopra il file reale del sito. La parte di fix che impedisce questo passaggio funziona già durante l'aggiornamento che la installa, perché la copia dei file nella posizione finale usa il codice nuovo. Resta però un'altra via. L'attaccante può configurare la copia temporanea con un proprio database, accedervi ed eseguire PHP prima che la copia venga cancellata.

Non tutti gli aggiornamenti espongono l'installer. I pacchetti completi lo includono sempre. Un pacchetto parziale, costruito per una specifica versione di partenza, espone il sito solo se contiene quei file. WordPress ripiega su un pacchetto completo se i file del core non corrispondono ai checksum ufficiali o in caso di reinstallazione. Secondo Bayram, il fattore decisivo è se l'updater già installato sul sito sia stato corretto, non se il pacchetto sia parziale o completo.

Sui siti 5.9 o successivi il vecchio codice nomina la cartella a partire dal file scaricato, quindi il nome è prevedibile. Nelle versioni dalla 4.4 alla 5.8 vengono aggiunti caratteri casuali, e il nome resta nascosto a meno che il sito non lo riveli in altro modo, ad esempio in un messaggio d'errore.

Sul fronte dei numeri, la copertura giornalistica riporta questi dati, tutti riferiti a tentativi bloccati dal firewall di Wordfence e non a compromissioni confermate:

- 62.969 attacchi bloccati in 24 ore, nei primi giorni dopo il rilascio.
- Oltre 240.000 tentativi bloccati al 6 novembre.

Anche la gravità è valutata in modo diverso. Wordfence assegna CVSS 8.1, con complessità d'attacco alta, mentre l'advisory di WordPress classifica il problema come bassa. Un'altra società, Xint, dichiara di aver scoperto la stessa race in modo indipendente. Il credito ufficiale di WordPress resta a Bayram.

## Cosa sappiamo e cosa no

**Confermato:**

- Versioni interessate: da 4.7 a 7.1.3\. La versione 7.1.4 è stata rilasciata il 28 ottobre, con rilasci corrispondenti per i rami più vecchi.
- La CISA ha inserito CVE-2026-119977 nel KEV il 3 novembre.
- Le versioni 4.6 e precedenti non ricevono più aggiornamenti di sicurezza, quindi per loro non esiste una correzione. Bayram sostiene che il difetto risalga fino a WordPress 2.7, del 2008, e consiglia di migrare a una versione supportata.
- Nei test di laboratorio di Wordfence la finestra di esposizione è durata solo pochi secondi.
- Dopo l'installazione di 7.1.4 (o del rilascio corretto per il proprio ramo), gli aggiornamenti successivi usano nomi di cartella casuali e un `wp-config.php` nella copia temporanea non viene più copiato sul file reale.

## Impatto pratico

La sequenza raccomandata da Bayram è questa.

1. **Bloccare l'accesso web a `wp-content/upgrade` prima di aggiornare.** WordPress lavora su quella cartella direttamente su disco, quindi il blocco non rompe gli aggiornamenti.
  - Nginx: `location ^~ /wp-content/upgrade/ { deny all; }`
  - Apache: `Require all denied` in un blocco `<Directory>` per quella cartella, nella configurazione del virtual host.
  - Solo con `.htaccess`: `RedirectMatch 403 ^/wp-content/upgrade/` nel file nella root di WordPress, sopra le regole di rewrite. Non va messo un `.htaccess` dentro `wp-content/upgrade`, perché il vecchio updater svuota quella cartella prima di estrarre l'aggiornamento e il file sparirebbe.
2. **Verificare** che una richiesta a `/wp-content/upgrade/` restituisca 403.
3. **Aggiornare** a 7.1.4 o al rilascio corretto per il proprio ramo.

L'alternativa indicata è l'aggiornamento manuale fuori dalla web root. Si fa il backup di file e database, si decomprime la nuova release in una cartella non servita dal web server e si copiano i file del core senza toccare `wp-config.php` e `wp-content`. Poi si esegue l'aggiornamento del database. Così non nasce nessun installer temporaneo in un percorso raggiungibile dal web. Il comando `wp core update` di WP-CLI non è un'alternativa valida, perché usa lo stesso updater e decomprime il pacchetto nella stessa cartella.

Per i siti rimasti su una versione vulnerabile dopo il rilascio, Wordfence suggerisce di cercare:

- richieste inattese a file PHP sotto `wp-content/upgrade`, in particolare `setup-config.php`, dal 28 ottobre in poi;
- account amministratore sconosciuti;
- plugin che nessuno ha installato;
- file PHP in `wp-content/upgrade` che nessuno ha messo lì.

Un'avvertenza per chi usa un plugin firewall. Wordfence segnala che le richieste puntano direttamente al file preparato, senza caricare WordPress, quindi un WAF che gira solo dentro WordPress potrebbe non vederle senza la modalità Extended Protection. Un blocco a livello di web server è più affidabile. Infine, l'assenza di voci sospette nei log non dimostra da sola che il sito non sia stato compromesso. Per gli ambienti più critici conviene una verifica dell'integrità dei file.

## Fonti

- [Installing the Fix for an Exploited WordPress Flaw Can Expose Some Sites One Last Time](https://thehackernews.com/2026/11/installing-fix-for-exploited-wordpress.html?ref=reinaldoferro.com)
- [WordPress RCE Flaw Draws Nearly 63,000 Attack Attempts in Just 24 Hours – The Hacker News](https://thehackernews.com/2026/10/wordpress-rce-flaw-draws-nearly-63000.html?ref=reinaldoferro.com)
- [CISA Adds One Known Exploited Vulnerability to Catalog – CISA](https://www.cisa.gov/news-events/alerts/2026/11/03/cisa-adds-one-known-exploited-vulnerability-catalog?ref=reinaldoferro.com)
- [CISA flags WordPress RCE flaw as actively exploited in attacks – BleepingComputer](https://www.bleepingcomputer.com/news/security/cisa-flags-wordpress-rce-flaw-as-actively-exploited-in-attacks/?ref=reinaldoferro.com)
- [WordPress Core Update Race: When the Update Becomes the Attack Path – Xint Blog](https://xint.io/blog/wordpress-core-update-attack?ref=reinaldoferro.com)