WordPress 7.1.4 corregge 22 falle, inclusa una RCE durante gli aggiornamenti
WordPress 7.1.4, pubblicato il 28 ottobre 2026, corregge 22 vulnerabilità trattate in 17 avvisi di sicurezza. Si tratta di un aumento sostanziale rispetto a WordPress 7.1.3, che tre settimane prima aveva risolto sette vulnerabilità. La maggior parte delle nuove falle richiede un account esistente, generalmente con il ruolo Contributor, ma due possono esporre informazioni o funzionalità senza autenticazione. La più grave è una race condition, ossia un problema di sicurezza causato da operazioni eseguite con tempistiche precise, che può portare alla remote code execution (RCE), cioè all'esecuzione di codice sul server interessato, mentre WordPress viene aggiornato.
Diversi avvisi riguardano il stored cross-site scripting (stored XSS), nel quale codice dannoso per il browser viene salvato nei contenuti del sito e viene eseguito quando un'altra persona apre la pagina interessata. Gli utenti con livello Contributor potevano sfruttare debolezze relative agli spazi nei delimitatori dei block, al selective refresh del Customizer, alla formattazione del block Categories, alle etichette di Comments Pagination e Post Navigation Link e a varie parti della Interactivity API. Le altre condizioni variavano: il problema dell'Interactivity Router richiedeva un account Author con l'autorizzazione a caricare file, mentre la schermata per la cancellazione dei dati personali richiedeva un account Editor e che un amministratore aprisse Tools e poi Erase Personal Data. Una correzione di hardening per multisite riguarda username senza escaping contenenti markup, quando tali nomi venivano memorizzati da qualcosa di esterno al core di WordPress e visualizzati da un amministratore di rete.
La RCE nel processo di aggiornamento non richiede alcun account, ma Patchstack descrive lo sfruttamento come impraticabile perché l'attaccante deve agire durante una finestra di soli pochi secondi. Durante l'installazione o l'aggiornamento, WordPress estrae un pacchetto software in wp-content/upgrade/, una directory che potrebbe essere resa pubblicamente accessibile dal web server. Prima della versione 7.1.4, la sua cartella temporanea ereditava dal pacchetto un nome prevedibile. Inoltre, la pulizia iniziale eliminava tutto ciò che si trovava nella directory, incluso il file index.php che normalmente impedisce la visualizzazione dell'elenco dei file.
Per quei pochi secondi, un'installazione WordPress estratta poteva quindi trovarsi a un indirizzo prevedibile e potenzialmente esplorabile. Includeva wp-admin/setup-config.php, che poteva avviarsi senza la configurazione del sito originale. Se un attaccante raggiungeva quel file al momento giusto, poteva eseguire l'installer usando un database sotto il proprio controllo mentre i file rimanevano nel document root del sito della vittima. Patchstack ha classificato il problema come AC:H, indicando un'elevata complessità dell'attacco, ma ha osservato che non richiede né un account né l'interazione dell'utente, che esiste da WordPress 2.8 e che si ripresenta durante ogni aggiornamento, inclusi quelli non supervisionati.
WordPress 7.1.4 aggiunge 16 caratteri casuali al nome della directory temporanea, ripristina index.php e smette di eliminare tale file. Patchstack ha inoltre individuato una modifica separata in update-core.php che inserisce wp-config.php nell'elenco dei file che non devono mai essere copiati dalla working directory. Un firewall eseguito tramite PHP non può intercettare la richiesta vulnerabile perché il pacchetto estratto carica i propri file WordPress e l'archivio ufficiale non contiene alcuna directory mu-plugins dalla quale potrebbe essere eseguito il firewall del sito. Patchstack consiglia quindi di bloccare a livello di web server l'accesso web a wp-content/upgrade/ e di verificare che i visitatori non possano visualizzarne il contenuto.
Sette dei 17 avvisi riguardano la Interactivity API, il sistema usato da WordPress per aggiungere ai block comportamenti eseguiti nel browser. La loro causa comune era KSES, il sistema di filtraggio di WordPress che controlla quale HTML possono salvare gli utenti privi di diritti di pubblicazione senza restrizioni. KSES consentiva qualsiasi attributo e valore data-*, mentre le direttive della Interactivity API utilizzano attributi come data-wp-interactive, data-wp-context e data-wp-bind--href. Un Contributor poteva salvare tali direttive in un post, dopodiché il browser di un visitatore le avrebbe elaborate.
I problemi risultanti includevano binding che creavano indirizzi javascript:, binding di event handler già rifiutati dal lato PHP e chiavi riservate come __proto__ che entravano in un merge del context e causavano prototype pollution, modificando le proprietà ereditate da altri oggetti del browser. Altre falle consentivano ai binding sugli elementi object di eludere i controlli esistenti su dati e tipi. Inoltre, a ogni iterazione un parser CSS ripeteva l'elaborazione, causando un denial of service che bloccava la scheda del browser del visitatore anziché il server. La versione 7.1.4 fa sì che KSES rimuova i binding che modificherebbero un valore convalidato, limita i binding degli elementi object nel processor PHP delle direttive e fa in modo che il runtime del browser rifiuti i target non sicuri. Il runtime per browser della Interactivity API è arrivato in WordPress 6.4, una release prima della classe PHP introdotta nella versione 6.5, perciò WordPress indica entrambe le versioni come interessate dallo stesso numero di problemi.
Un'altra falla consentiva al contenuto dei post di mettere in shadow i dati degli Script Module. La Interactivity API utilizzava getElementById(), che restituisce il primo elemento con l'ID richiesto, indipendentemente dal suo tipo. Poiché WordPress inseriva i dati autentici dello script in wp_footer dopo il post, un contenuto con un ID corrispondente poteva apparire per primo e fornire lo stato al runtime. La versione 7.1.4 ora verifica che l'elemento selezionato sia effettivamente un elemento script.
Sono stati corretti anche due problemi del Customizer. Il selective refresh considerava attendibili gli attributi data-customize-partial-* nel contenuto di preview e passava un selector fornito alla funzione $() di jQuery. Un valore che iniziava con il carattere minore di poteva essere interpretato come HTML da creare invece che come selector da cercare. La correzione utilizza .find(), che interpreta esclusivamente i selector. Separatamente, una richiesta di preview priva di un UUID del changeset poteva adottare il changeset non pubblicato più recente senza verificare chi lo avesse creato o se il visitatore disponesse dell'autorizzazione. Ciò ne esponeva l'identificatore e mostrava la preview in forma anonima, anche se la modifica dei relativi valori richiedeva comunque le autorizzazioni appropriate. WordPress 7.1.4 ora richiede la capability customize.
Tre correzioni relative ai block riguardano contenuti che venivano reinterpretati dopo il filtraggio. Il block Categories inseriva un'etichetta di menu a discesa filtrata in una format string di sprintf(), consentendo alle direttive di formattazione di espandersi successivamente. I block Image e Playlist utilizzavano testo influenzabile dall'attaccante come replacement di preg_replace(), nel quale PHP poteva espandere riferimenti come $0 e inserire un tag nell'attributo di un altro tag. Ora entrambi utilizzano la HTML API. I block Comments Pagination e Post Navigation Link ora applicano l'escaping ai propri attributi label prima dell'output.
La falla nel delimitatore dei block derivava dal fatto che il parser PHP del server e il parser JavaScript dell'editor interpretavano diversamente gli spazi. JavaScript riconosceva spazi unificatori, diversi spazi Unicode e un byte order mark che PHP non riconosceva. Di conseguenza, un delimitatore appositamente costruito poteva essere un commento inerte sul server ma un vero block con attributi controllati dall'attaccante nell'editor. La versione 7.1.4 limita tutti i parser agli stessi cinque caratteri di spaziatura.