WordPress, la patch 7.1.4 lascia un’ultima finestra agli hacker: come evitare la RCE durante l’aggiornamento

🛡️ Executive Summary

• WordPress rimane esposto durante il primo aggiornamento correttivo. La vulnerabilità CVE-2026-119977 può ancora essere sfruttata mentre una versione vulnerabile installa la patch, perché l’estrazione dei file viene eseguita dal vecchio codice.
• Gli attaccanti possono eseguire codice PHP senza autenticazione. La finestra temporanea riguarda le installazioni che estraggono una copia funzionante di WordPress in una directory raggiungibile dal web. CISA ha già inserito la vulnerabilità nel catalogo delle falle sfruttate attivamente.
• La mitigazione consiste nel bloccare l’accesso HTTP a wp-content/upgrade prima dell’aggiornamento. Picus Security raccomanda regole applicate al web server oppure un aggiornamento manuale eseguito fuori dalla directory pubblica.

WordPress 7.1.4 corregge una vulnerabilità che permette l’esecuzione remota di codice senza autenticazione, ma la stessa procedura utilizzata per installare la patch può lasciare il sito esposto per un’ultima volta. Il problema, identificato come CVE-2026-119977, viene approfondito dal ricercatore Umut Bayram di Picus Security, che dimostra come il sistema di aggiornamento continui a utilizzare temporaneamente il codice vulnerabile della versione precedente. Durante l’installazione, una copia dei file di WordPress può diventare accessibile attraverso la directory wp-content/upgrade, consentendo a un attaccante di intervenire prima che il processo venga completato. La vulnerabilità, corretta ufficialmente il 28 ottobre 2026, è già oggetto di tentativi di sfruttamento e dal 3 novembre compare nel catalogo Known Exploited Vulnerabilities di CISA. La raccomandazione operativa cambia quindi: non basta aggiornare immediatamente, ma occorre proteggere la directory temporanea prima di avviare l’installazione.

CVE-2026-119977 colpisce il sistema di aggiornamento di WordPress

La vulnerabilità interessa il Core di WordPress, non un plugin o un tema di terze parti, ed è riconducibile a una race condition nel processo di aggiornamento. Quando viene utilizzato un pacchetto completo, WordPress estrae temporaneamente i file della nuova versione all’interno di wp-content/upgrade, prima di copiarli nella directory principale del sito. Nelle versioni vulnerabili, il percorso temporaneo può essere prevedibile e contenere anche setup-config.php, il componente utilizzato per configurare una nuova installazione. Se il web server consente l’accesso a quella directory e l’esecuzione di PHP, un aggressore privo di credenziali può tentare di raggiungere l’installer durante i pochi secondi nei quali la copia temporanea rimane disponibile.

La catena originaria consente di creare un file wp-config.php malevolo nella directory di aggiornamento e sfruttarne la successiva copia per sostituire la configurazione del sito. In determinate condizioni, l’installazione viene così collegata a un database controllato dall’attaccante, che può ottenere privilegi amministrativi ed eseguire codice PHP. Wordfence attribuisce alla falla un punteggio CVSS di 8,1, mentre la sua inclusione nel catalogo CISA conferma evidenze di sfruttamento attivo, senza stabilire quanti siti siano stati effettivamente compromessi. Le attività automatizzate erano emerse immediatamente dopo la pubblicazione della correzione, con 62.969 tentativi bloccati da Wordfence nell’arco di 24 ore. Il numero descrive richieste malevole, non altrettante compromissioni riuscite.

Leggi anche: WordPress sotto attacco: quasi 63.000 tentativi contro una falla RCE

Perché installare WordPress 7.1.4 può lasciare il sito ancora vulnerabile

La scoperta più importante riguarda la distinzione fra il codice che estrae l’aggiornamento e quello che installa i file estratti. Quando un sito passa da WordPress 7.1.3 o da un’altra versione vulnerabile alla release corretta, il pacchetto viene inizialmente decompresso utilizzando il vecchio sistema di aggiornamento. La patch 7.1.4 introduce una directory temporanea con un suffisso casuale e impedisce che wp-config.php venga copiato sopra la configurazione originale, ma soltanto quest’ultima protezione entra in funzione già durante il primo aggiornamento. Il percorso temporaneo può quindi rimanere prevedibile perché viene creato attraverso le vecchie funzioni del Core.

Secondo la ricerca tecnica originale di Picus Security, in questa situazione l’aggressore non riesce più a sostituire il file di configurazione principale, ma può ancora configurare la copia temporanea con un proprio database ed eseguire codice PHP attraverso il processo del web server. Da quella posizione può raggiungere i file dell’installazione effettiva prima che la cartella venga eliminata. Il rischio non si manifesta necessariamente in ogni aggiornamento: i pacchetti completi comprendono i file necessari all’attacco, mentre quelli parziali risultano sfruttabili soltanto se contengono i componenti indispensabili per avviare l’installer. Anche gli aggiornamenti automatici possono utilizzare il vecchio sistema di estrazione e il comando wp core update di WP-CLI non elimina questa condizione, perché richiama il medesimo meccanismo. Soltanto gli aggiornamenti successivi all’installazione della versione corretta utilizzano integralmente le nuove protezioni.

Come proteggere wp-content/upgrade prima di aggiornare WordPress

La contromisura principale consiste nel negare qualsiasi accesso web alla directory wp-content/upgrade, lasciando invece WordPress libero di utilizzare i file attraverso il filesystem. Picus Security raccomanda di applicare il blocco direttamente alla configurazione del server. Su Nginx è possibile utilizzare location ^~ /wp-content/upgrade/ { deny all; }, mentre su Apache il divieto può essere applicato attraverso una direttiva <Directory> con Require all denied. Negli ambienti nei quali è possibile intervenire soltanto sul file .htaccess principale, la ricerca propone la direttiva RedirectMatch 403 ^/wp-content/upgrade/, da inserire prima delle regole di riscrittura standard di WordPress. La soluzione deve essere compatibile con la configurazione effettiva del server e verificata prima dell’aggiornamento: le richieste HTTP dirette alla cartella protetta devono ricevere una risposta 403.

Un’avvertenza riguarda la posizione della protezione. Non bisogna collocare il file .htaccess dentro wp-content/upgrade, perché il vecchio sistema di aggiornamento può cancellare il contenuto della directory prima di estrarre i nuovi file, eliminando proprio la regola necessaria nel momento più delicato. In alternativa, il ricercatore indica un aggiornamento manuale fuori dalla document root, estraendo la nuova versione in una directory non accessibile dal web e copiando successivamente i file del Core senza sovrascrivere wp-config.php e wp-content. Prima dell’intervento è opportuno eseguire un backup verificato di file e database. La protezione della cartella può essere mantenuta anche dopo l’aggiornamento, perché non è necessario renderla pubblicamente accessibile per il normale funzionamento del CMS.

Continua con:

WordPress 7.1.2 corregge CVE-2026-87902: path traversal pre-auth fino alla RCE

Click2Shell trasforma un clic in una shell WordPress: patch urgente sul Core

WordPress 7.1.4 corregge la falla, ma servono controlli anche dopo l’installazione

La release WordPress 7.1.4, disponibile dal 28 ottobre, introduce tre interventi specifici: nomi casuali per le directory temporanee, conservazione del file che impedisce l’esposizione dell’elenco delle cartelle e esclusione di wp-config.php dalla copia dei file del Core. La correzione è stata distribuita anche sui rami precedenti ancora coperti dagli aggiornamenti di sicurezza, fino alla serie 4.7. Le versioni ancora più vecchie non ricevono questa protezione e devono essere migrate a un ramo supportato. Rimane essenziale distinguere i sistemi già aggiornati correttamente da quelli che devono ancora affrontare il primo passaggio: un sito sul quale la versione corretta è già installata non presenta più la stessa finestra prevedibile nei successivi aggiornamenti, mentre l’assenza di anomalie visibili non permette di escludere una compromissione precedente.

Gli amministratori devono verificare la presenza nei log di richieste anomale verso file PHP contenuti in wp-content/upgrade, controllare la comparsa di account amministrativi sconosciuti, plugin mai installati e file PHP inattesi. Nei casi sospetti occorre preservare le evidenze, controllare l’integrità del filesystem e valutare la rotazione delle credenziali e dei segreti accessibili al processo WordPress. La vulnerabilità dimostra che la disponibilità di una patch non coincide automaticamente con una procedura di aggiornamento sicura: anche il passaggio fra una versione vulnerabile e una corretta può diventare una superficie d’attacco. Il bollettino ufficiale WordPress 7.1.4 conferma la correzione, mentre la ricerca di Picus Security chiarisce perché bloccare l’accesso web alla directory temporanea rappresenti la precauzione più importante prima di installarla.