L’installazione della correzione per un difetto WordPress sfruttato può esporre alcuni siti…

Installare la correzione per un difetto WordPress sfruttato può esporre alcuni siti un’ultima volta Swati Khandelwal 06 novembre 2026 Vulnerabilità /Sicurezza web Alcuni siti WordPress possono ancora essere attaccati mentre installano la correzione per un difetto sfruttato attivamente, secondo Umut Bayram, il ricercatore di Picus Security che lo ha trovato

. L’aggiornamento che installa la correzione decomprime ancora i file utilizzando il vecchio codice senza patch del sito, in modo che un utente malintenzionato che colpisce al momento giusto possa eseguire il codice sul server. Il ricercatore consiglia di bloccare l’accesso web alla cartella wp-content/upgrade del sito prima dell’aggiornamento. Il difetto, identificato come CVE-2026-119977, interessa WordPress da 4.7 a 7.1.3

. Durante un aggiornamento di base che utilizza un pacchetto completo, WordPress decomprime una copia della nuova versione in una cartella temporanea all’interno di wp-content/upgrade. Tale copia include il programma di installazione di WordPress e il server web di solito può raggiungerlo. Un utente malintenzionato senza account che può determinare il nome della cartella e accedere al programma di installazione prima che WordPress elimini la copia può finire per eseguire codice sul server. Gli Stati Uniti

Cybersecurity and Infrastructure Security Agency (CISA) ha aggiunto la falla al suo catalogo di vulnerabilità sfruttate note all’inizio di questa settimana. WordPress ha rilasciato la correzione la scorsa settimana nella versione 7. 1. 4 e negli aggiornamenti corrispondenti per i rami più vecchi fino alla 4. 7, tutti elencati nell’advisory sulla sicurezza di itssecurity. La correzione assegna alla cartella temporanea un nome casuale.

Ma l’aggiornamento che installa la correzione decomprime i suoi file utilizzando il vecchio codice già presente sul sito, come codeshow updaterdi WordPress

. Sui siti che eseguono 5.9 o versioni successive, quel vecchio codice denomina la cartella dopo il file scaricato, in modo che il nome possa essere previsto un’ultima volta. Prima della correzione, un utente malintenzionato poteva utilizzare il programma di installazione per scrivere un nuovo file di configurazione, wp-config.php, nella copia temporanea. L’aggiornamento sovrascriverebbe quindi il file reale del sito con quel file

. La parte della correzione che interrompe questa operazione funziona già durante l’aggiornamento che la installa, perché WordPress copia i file in posizione utilizzando il nuovo codice. Un utente malintenzionato che intercetta la finestra durante tale aggiornamento può comunque impostare la copia temporanea di WordPress con il proprio database, accedervi ed eseguire il codice PHP con le autorizzazioni del server Web prima che la copia venga eliminata, afferma Bayram nell’articolo istecnico

Da lì, l’utente malintenzionato può leggere o scrivere file nel sito WordPress live. Chi viene esposto durante l’aggiornamento Non tutti gli aggiornamenti espongono l’installatore, afferma il ricercatore. I pacchetti completi includono sempre i file di installazione. Un pacchetto parziale più piccolo, costruito per una specifica versione iniziale, espone un sito solo se capita di contenerli.

Sui siti che consentono aggiornamenti automatici in background, WordPress installa la correzione automaticamente, tramite lo stesso programma di aggiornamento e gli stessi passaggi

. The Hacker News ha controllato oggi il servizio di aggiornamento di WordPress.org per diverse versioni. Per gli aggiornamenti all’interno di una filiale, come da 7.1.3 a 7.1.4, ha offerto un pacchetto parziale, anche per gli aggiornamenti automatici. Per un passaggio da una filiale più vecchia, come da 7.0.7 a 7.1.4, offriva solo pacchetti completi. Da 4.4 a 5.8, il vecchio codice aggiunge caratteri casuali al nome della cartella

. Ciò nasconde il nome a meno che il sito non lo riveli in qualche altro modo, ad esempio in un messaggio di errore, afferma il ricercatore. Una volta installato 7.1.4 o una correzione di ramo, gli aggiornamenti successivi utilizzano un nome di cartella casuale e un file wp-config.php nella copia temporanea non viene mai copiato su quello reale. Cosa fare prima di aggiornare La prima raccomandazione del ricercatore è di impedire al server web di servire wp-content/upgrade

WordPress funziona con quella cartella direttamente su disco, quindi bloccare l’accesso al web non interrompe gli aggiornamenti, dice. Bloccare la cartella nella configurazione del server web. Su Nginx, aggiungi la posizione ^~ /wp-content/upgrade/ { deny all; }. Su Apache, aggiungi Richiedi tutto negato all’interno di un blocco per quella cartella nella configurazione dell’host virtuale. Se puoi modificare solo. htaccess, aggiungi RedirectMatch 403 ^/wp-content/upgrade/ al file.

htaccess nella root di WordPress, sopra le regole di riscrittura di WordPress

. Non inserire un file.htaccess all’interno di wp-content/upgrade stesso. Il vecchio programma di aggiornamento elimina tutto ciò che si trova in quella cartella prima di decomprimere un aggiornamento, in modo che il file sparisca quando è necessario. Confermare che una richiesta a /wp-content/upgrade/ restituisca un errore 403. Aggiorna a 7.1.4 o alla versione fissa per la tua filiale. L’altro percorso sicuro, dice, è un aggiornamento manuale fatto al di fuori della root web, la cartella che serve il web server

Eseguire il backup dei file e del database del sito, decomprimere la nuova versione in una cartella che il server Web non serve, copiare i file principali in posizione senza toccare wp-config. php o wp-content, quindi eseguire l’aggiornamento del database WordPress. In questo modo, nessun programma di installazione temporaneo viene mai creato in una cartella raggiungibile dal web.

Il comando wp core update di WP-CLI non è sostitutivo, perché esegue lo stesso programma di aggiornamento e decomprime il pacchetto nella stessa cartella

. WordPress 4.6 e versioni precedenti non ricevono più aggiornamenti di sicurezza, quindi non ci sono correzioni per loro. Il ricercatore dice che il difetto risale a WordPress 2.7, rilasciato nel 2008, e che quei siti dovrebbero passare a una versione supportata. Attacchi e cosa controllare L’aggiunta del catalogo di CISA all’inizio di questa settimana si basava su prove di sfruttamento attivo, ma l’agenzia non ha descritto gli attacchi

Wordfence, la società di sicurezza di WordPress che ha assegnato l’identificativo CVE, ha iniziato i tentativi di attacco nove minuti dopo aver implementato una regola firewall per il difetto il giorno del rilascio. Due delle fonti più impegnate hanno continuato a controllare piccoli gruppi di siti per circa 14,5 ore, che l’azienda afferma, nella sua analisi degli attacchi, si allinea ai tentativi di cogliere il momento in cui un sito si aggiorna.

Il suo punteggio per il difetto nel record CVE è 8,1 su 10 sulla scala CVSS