Il 10 marzo 2026 il team di sicurezza di WordPress ha rilasciato la versione 6.9.2, una security release che corregge 10 vulnerabilità nel core e in una libreria PHP esterna. Nella mia esperienza di sysadmin che gestisce decine di installazioni WordPress su server Plesk, vi posso dire che questa è stata una delle release più movimentate degli ultimi anni: tre aggiornamenti in meno di 24 ore (6.9.2, 6.9.3 e 6.9.4) per chiudere completamente tutte le falle.
Le vulnerabilità corrette spaziano dal Blind Server-Side Request Forgery (SSRF) allo Stored Cross-Site Scripting nei menu di navigazione, passando per un Regex Denial of Service e una PoP-chain (Property Oriented Programming) nell’HTML API. Tutte richiedono autenticazione almeno a livello subscriber, ma questo non le rende meno pericolose: un singolo account compromesso basta per sfruttarle. Vi mostro come ho aggiornato i miei siti e cosa ho verificato per assicurarmi che tutto fosse a posto.
Le 10 Vulnerabilità di Sicurezza Corrette in WordPress 6.9.2
Ecco l’elenco completo delle 10 falle corrette, con i dettagli tecnici e i ricercatori che le hanno scoperte:
1. Blind SSRF (CVE-2026-3901)
Una vulnerabilità di tipo Server-Side Request Forgery in modalità “blind” permette a un attaccante autenticato di forzare il server a effettuare richieste HTTP verso host interni o esterni senza che la risposta venga esposta direttamente. In ambienti cloud o con servizi interni esposti sulla rete locale (metadata endpoint AWS/GCP, Redis, Elasticsearch), questo tipo di falla può avere conseguenze devastanti. Scoperta dal ricercatore sibwtf e successivamente segnalata da altri ricercatori mentre la fix era in lavorazione.
2. PoP-Chain nell’HTML API e Block Registry
Una debolezza nella catena Property Oriented Programming (PoP) all’interno dell’HTML API e del Block Registry. Questo tipo di vulnerabilità consente a un attaccante di concatenare chiamate a metodi di oggetti PHP deserializzati per ottenere esecuzione di codice arbitrario. Scoperta da Phat RiO.
3. Regex DoS nei Numeric Character References
Un’espressione regolare mal costruita nella gestione dei numeric character references può essere sfruttata per provocare un Denial of Service tramite backtracking catastrofico. Un input appositamente costruito può bloccare il processo PHP per minuti, rendendo il sito inaccessibile. Identificata da Dennis Snell del WordPress Security Team stesso.
4. Stored XSS nei Menu di Navigazione
Una vulnerabilità di Cross-Site Scripting persistente nei menu di navigazione consente di iniettare codice JavaScript malevolo che viene eseguito nel browser di ogni visitatore che visualizza il menu. Particolarmente critica perché i menu sono presenti su tutte le pagine del sito. Scoperta da Phill Savage.
5. Authorization Bypass in AJAX query-attachments
Un bypass dell’autorizzazione nell’handler AJAX query-attachments permette a utenti con ruoli bassi di accedere a media e allegati che non dovrebbero poter visualizzare. Segnalata da Vitaly Simonovich.
6. Stored XSS via data-wp-bind
La direttiva data-wp-bind, introdotta con l’Interactivity API di WordPress, conteneva una falla che consentiva l’iniezione di script persistenti. Scoperta da kaminuma.
7. XSS nell’Override dei Template Client-Side
Una vulnerabilità XSS che permette di sovrascrivere i template lato client nell’area di amministrazione. Un attaccante può alterare il rendering dell’interfaccia admin per altri utenti. Scoperta da Asaf Mozes.
8. Path Traversal in PclZip (CVE-2026-3907)
Una vulnerabilità di path traversal nella libreria PclZip utilizzata da WordPress per la gestione degli archivi ZIP. Un attaccante potrebbe estrarre file in directory arbitrarie del server. Scoperta indipendentemente da Francesco Carlucci e kaminuma. Questa è stata una delle tre patch incomplete in 6.9.2, corretta definitivamente solo nella 6.9.4.
9. Authorization Bypass nella funzione Notes (CVE-2026-3906)
Un bypass dell’autorizzazione nella funzionalità Notes consente ad utenti non autorizzati di accedere o modificare note riservate. Scoperta da kaminuma. Anche questa patch era incompleta in 6.9.2.
10. XXE nella libreria getID3 (CVE-2026-3908)
Una vulnerabilità di XML External Entity injection nella libreria esterna getID3, utilizzata da WordPress per leggere i metadati dei file multimediali (audio, video). Il team di sicurezza ha lavorato a stretto contatto con il maintainer James Heinrich per coordinare la fix. Scoperta da Youssef Achtatal. Terza patch incompleta, chiusa nella 6.9.4.
Il Caos dei Tre Aggiornamenti in 24 Ore
Quello che è successo dopo il rilascio della 6.9.2 merita di essere raccontato, perché è un caso di studio su come non gestire una security release:
- 10 marzo, 16:00 UTC — Rilascio di WordPress 6.9.2 con le 10 fix di sicurezza.
- 10 marzo, ~21:00 UTC — Report di siti che mostrano white screen of death. La patch di sicurezza ha introdotto una regressione nel caricamento dei template che causa crash in determinati temi. Rilascio d’emergenza della 6.9.3.
- 11 marzo, 22:00 UTC — Il Security Team scopre che tre delle dieci patch non erano state applicate completamente: PclZip path traversal (CVE-2026-3907), Notes authorization bypass (CVE-2026-3906) e XXE in getID3 (CVE-2026-3908). Rilascio della 6.9.4.
Nella mia esperienza, questo è il motivo per cui non abilito mai gli aggiornamenti automatici major sui siti di produzione critici senza un ambiente di staging. Ma per le security release, la velocità di aggiornamento è fondamentale. Nel mio caso, come vi racconto nel mio articolo sulla protezione WordPress con virtual patching e WAF, utilizzo Patchstack come prima linea di difesa proprio per coprire la finestra temporale tra disclosure e aggiornamento.
Come Aggiorno a WordPress 6.9.4 in Sicurezza
Vi mostro la procedura che seguo sui miei server Plesk per aggiornare WordPress in modo sicuro. L’obiettivo è arrivare direttamente alla 6.9.4 (che include tutte le fix complete), saltando le versioni intermedie problematiche.
Step 1: Backup Completo
Prima di qualsiasi aggiornamento, eseguo sempre un backup completo. Come ho spiegato nel mio articolo sui backup automatici su Plesk con destinazione S3, avere un backup incrementale recente è la prima regola:
# Backup del database
mariadb-dump -u admin -p$(cat /etc/psa/.psa.shadow) wp_dxdqe > /root/backup_wp_pre694_$(date +%Y%m%d).sql
# Backup dei file WordPress
tar czf /root/backup_wp_files_pre694_$(date +%Y%m%d).tar.gz /var/www/vhosts/darioiannascoli.it/httpdocs/blog/Step 2: Verifico la Versione Attuale
# Con WP-CLI su Plesk
/opt/plesk/php/8.3/bin/php /usr/local/bin/wp core version --path=/var/www/vhosts/darioiannascoli.it/httpdocs/blog --allow-root
# Controllo aggiornamenti disponibili
/opt/plesk/php/8.3/bin/php /usr/local/bin/wp core check-update --path=/var/www/vhosts/darioiannascoli.it/httpdocs/blog --allow-rootStep 3: Aggiornamento
# Aggiorno direttamente alla 6.9.4
/opt/plesk/php/8.3/bin/php /usr/local/bin/wp core update --path=/var/www/vhosts/darioiannascoli.it/httpdocs/blog --allow-root
# Verifico la versione installata
/opt/plesk/php/8.3/bin/php /usr/local/bin/wp core version --path=/var/www/vhosts/darioiannascoli.it/httpdocs/blog --allow-rootStep 4: Aggiorno il Database
/opt/plesk/php/8.3/bin/php /usr/local/bin/wp core update-db --path=/var/www/vhosts/darioiannascoli.it/httpdocs/blog --allow-rootStep 5: Verifico il Funzionamento
Dopo l’aggiornamento, controllo sempre:
- Il sito è raggiungibile e non mostra white screen
- L’area admin funziona correttamente
- I plugin sono compatibili (nessun errore PHP nel log)
- La cache è stata invalidata
# Flush della cache
/opt/plesk/php/8.3/bin/php /usr/local/bin/wp cache flush --path=/var/www/vhosts/darioiannascoli.it/httpdocs/blog --allow-root
# Verifico errori nel log PHP
tail -50 /var/log/php-fpm/error.logAnalisi Tecnica delle Vulnerabilità Più Critiche
Blind SSRF: Perché è Pericolosa
La vulnerabilità Blind SSRF è particolarmente insidiosa in ambienti cloud. Anche se l’attaccante non vede la risposta della richiesta forzata, può:
- Effettuare port scanning della rete interna
- Accedere ai metadata endpoint cloud (come
169.254.169.254su AWS) per rubare credenziali IAM - Interagire con servizi interni non esposti (Redis, Memcached, database)
- Provocare azioni su servizi interni tramite richieste GET/POST forgiate
Sul mio server Plesk, ho mitigato questo rischio anche prima della patch configurando regole firewall che bloccano le richieste HTTP in uscita dal processo PHP verso la rete locale, ad eccezione dei servizi necessari.
PoP-Chain: Object Injection nell’HTML API
Le PoP-chain (Property Oriented Programming) sono catene di gadget PHP che sfruttano la deserializzazione di oggetti. Quando un attaccante riesce a controllare i dati passati a unserialize(), può concatenare metodi __destruct(), __wakeup() e __toString() di classi esistenti nel codebase per ottenere effetti arbitrari, dall’eliminazione di file all’esecuzione di codice.
Il fatto che questa catena sia stata trovata nell’HTML API e nel Block Registry è significativo: sono componenti utilizzati intensamente da Gutenberg e dai temi a blocchi, quindi la superficie di attacco è ampia.
Regex DoS: Il Backtracking Catastrofico
Il Regular Expression Denial of Service (ReDoS) sfrutta pattern regex che, con input specifici, causano un numero esponenziale di backtracking steps. Nel caso dei numeric character references (come • o •), un input malformato e sufficientemente lungo può bloccare il processo PHP per secondi o minuti. Su server condivisi questo può impattare tutti i siti ospitati.
Backporting: Quali Versioni Sono Interessate
Le fix di sicurezza sono state backportate a tutte le versioni supportate a partire dalla 4.7. Questo significa che anche se usate una versione vecchia di WordPress (sconsigliato), avete ricevuto o potete ricevere la patch. Le versioni aggiornate sono:
- WordPress 6.9.4 (branch corrente)
- WordPress 6.8.x, 6.7.x, 6.6.x, 6.5.x
- Fino alla 4.7.x
Se gestite siti WordPress aziendali, vi consiglio di leggere anche il mio articolo su come configuro un server Plesk per WordPress ad alte prestazioni e sicurezza per un quadro completo delle best practice.
Hardening Post-Aggiornamento: Cosa Controllare
Dopo aver aggiornato a WordPress 6.9.4, nella mia procedura standard eseguo sempre questi controlli aggiuntivi:
Verifica Integrità dei File Core
/opt/plesk/php/8.3/bin/php /usr/local/bin/wp core verify-checksums --path=/var/www/vhosts/darioiannascoli.it/httpdocs/blog --allow-rootScansione Plugin Vulnerabili
# Lista plugin con aggiornamenti disponibili
/opt/plesk/php/8.3/bin/php /usr/local/bin/wp plugin list --update=available --path=/var/www/vhosts/darioiannascoli.it/httpdocs/blog --allow-rootAudit degli Utenti
Dato che tutte le 10 vulnerabilità richiedono autenticazione, è fondamentale verificare che non ci siano utenti sconosciuti o account compromessi:
# Lista tutti gli utenti con i rispettivi ruoli
/opt/plesk/php/8.3/bin/php /usr/local/bin/wp user list --fields=ID,user_login,user_email,roles --path=/var/www/vhosts/darioiannascoli.it/httpdocs/blog --allow-rootRevisione dei Certificati SSL
A proposito di sicurezza, assicuratevi che i vostri certificati SSL siano in ordine. Ho scritto una guida completa su come automatizzare il rinnovo dei certificati SSL con Certbot e Let’s Encrypt.
Lezioni Apprese dal Rilascio Caotico
Il caso WordPress 6.9.2→6.9.4 ci insegna alcune lezioni importanti:
- Testare le security patch su staging — La regressione del white screen avrebbe potuto essere catturata con test più approfonditi prima del rilascio.
- Verificare che le patch siano complete — Tre fix su dieci erano incomplete. Un processo di review più rigoroso avrebbe evitato il terzo rilascio.
- Avere sempre un rollback plan — Il mio backup pre-aggiornamento mi ha dato la tranquillità di poter tornare indietro in caso di problemi.
- Il virtual patching copre la finestra critica — Strumenti come Patchstack hanno protetto i siti nelle ore tra la disclosure e il rilascio della fix completa (6.9.4).
- Monitorare i log attivamente — Dopo ogni security release, controllo i log di accesso per tentativi di exploitation delle vulnerabilità appena divulgate.
Come ho discusso nell’articolo sui SOC autonomi e threat prediction con AI, il monitoraggio continuo è la chiave per una sicurezza proattiva piuttosto che reattiva.
FAQ
WordPress 6.9.2 è sicuro da installare o devo saltare direttamente alla 6.9.4?
Se il vostro sistema di aggiornamento automatico vi propone la 6.9.4, installatela direttamente. La 6.9.2 conteneva una regressione che causava white screen su alcuni temi e tre patch di sicurezza incomplete (CVE-2026-3906, CVE-2026-3907, CVE-2026-3908). La 6.9.4 include tutte le fix complete senza la regressione. Se avete già installato la 6.9.2 o 6.9.3, aggiornate immediatamente alla 6.9.4.
Le vulnerabilità di WordPress 6.9.2 possono essere sfruttate senza autenticazione?
No, tutte e 10 le vulnerabilità corrette richiedono autenticazione almeno a livello subscriber. Questo non significa che siate al sicuro: basta un singolo account compromesso, un plugin con registrazione aperta, o un sito con registrazione utenti attiva per fornire il punto d’ingresso necessario. Controllate sempre la lista utenti e disabilitate la registrazione se non necessaria.
Devo aggiornare subito o posso aspettare?
Aggiornate il prima possibile. Le vulnerabilità sono state divulgate pubblicamente e i dettagli tecnici sono disponibili. I proof-of-concept per alcune di queste falle sono già circolati online. Ogni ora di ritardo aumenta il rischio di exploitation. Se non potete aggiornare immediatamente, attivate un WAF con virtual patching come Patchstack o Wordfence per coprire la finestra di vulnerabilità.
Come verifico se il mio sito WordPress è stato compromesso prima dell’aggiornamento?
Controllate i log di accesso per richieste sospette verso endpoint AJAX e REST API, verificate l’integrità dei file core con wp core verify-checksums, controllate la lista utenti per account sconosciuti, e verificate che non ci siano file PHP sospetti nelle directory uploads o nei temi. Se trovate anomalie, eseguite un’analisi forense completa prima di procedere con l’aggiornamento.
Le versioni precedenti di WordPress (6.8, 6.7, ecc.) sono interessate da queste vulnerabilità?
Sì, le vulnerabilità interessano tutte le versioni di WordPress fino alla 4.7. Le fix sono state backportate a tutti i branch supportati. Se utilizzate una versione precedente alla 6.9, aggiornate alla minor release più recente del vostro branch (ad esempio 6.8.x, 6.7.x). Tuttavia, il consiglio è sempre quello di utilizzare l’ultima versione stabile disponibile.
Conclusione
L’aggiornamento a WordPress 6.9.4 è obbligatorio per chiunque gestisca un sito WordPress. Le 10 vulnerabilità corrette — dal Blind SSRF alla PoP-chain nell’HTML API, passando per Stored XSS nei menu e Regex DoS — rappresentano un rischio concreto, soprattutto considerando che i dettagli tecnici sono ormai pubblici.
Il rilascio caotico con tre versioni in 24 ore ci ricorda che anche il software open source più diffuso al mondo non è immune da errori nel processo di rilascio. Ma la reazione rapida del Security Team dimostra anche la forza della comunità WordPress nel correggere i propri errori.
Se gestite un server con più installazioni WordPress, come faccio io su Plesk, automatizzate il processo di aggiornamento delle security release e mantenete sempre un layer di virtual patching e WAF come prima linea di difesa. E soprattutto: fate sempre un backup prima di aggiornare.
Avete già aggiornato i vostri siti? Avete riscontrato problemi con la regressione della 6.9.2? Raccontatemi la vostra esperienza nei commenti.