{"id":1635,"date":"2026-03-24T09:08:02","date_gmt":"2026-03-24T08:08:02","guid":{"rendered":"https:\/\/darioiannascoli.it\/blog\/aggiornamento-wordpress-692-vulnerabilita-sicurezza-marzo-2026-ssrf-xss-regex-dos\/"},"modified":"2026-03-24T09:08:02","modified_gmt":"2026-03-24T08:08:02","slug":"aggiornamento-wordpress-692-vulnerabilita-sicurezza-marzo-2026-ssrf-xss-regex-dos","status":"publish","type":"post","link":"https:\/\/darioiannascoli.it\/blog\/aggiornamento-wordpress-692-vulnerabilita-sicurezza-marzo-2026-ssrf-xss-regex-dos\/","title":{"rendered":"Come Aggiorno a WordPress 6.9.2 e Correggo le 10 Vulnerabilit\u00e0 di Sicurezza di Marzo 2026: Blind SSRF, Stored XSS nei Menu, Regex DoS e PoP-Chain nell’HTML API"},"content":{"rendered":"

Il 10 marzo 2026 il team di sicurezza di WordPress ha rilasciato la versione 6.9.2<\/strong>, una security release che corregge 10 vulnerabilit\u00e0<\/strong> 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 \u00e8 stata una delle release pi\u00f9 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.<\/p>\n

Le vulnerabilit\u00e0 corrette spaziano dal Blind Server-Side Request Forgery<\/em> (SSRF) allo Stored Cross-Site Scripting<\/em> nei menu di navigazione, passando per un Regex Denial of Service<\/em> e una PoP-chain<\/em> (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.<\/p>\n

Le 10 Vulnerabilit\u00e0 di Sicurezza Corrette in WordPress 6.9.2<\/h2>\n

Ecco l’elenco completo delle 10 falle corrette, con i dettagli tecnici e i ricercatori che le hanno scoperte:<\/p>\n

1. Blind SSRF (CVE-2026-3901)<\/h3>\n

Una vulnerabilit\u00e0 di tipo Server-Side Request Forgery<\/em> in modalit\u00e0 “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\u00f2 avere conseguenze devastanti. Scoperta dal ricercatore sibwtf<\/strong> e successivamente segnalata da altri ricercatori mentre la fix era in lavorazione.<\/p>\n

2. PoP-Chain nell’HTML API e Block Registry<\/h3>\n

Una debolezza nella catena Property Oriented Programming<\/em> (PoP) all’interno dell’HTML API e del Block Registry. Questo tipo di vulnerabilit\u00e0 consente a un attaccante di concatenare chiamate a metodi di oggetti PHP deserializzati per ottenere esecuzione di codice arbitrario. Scoperta da Phat RiO<\/strong>.<\/p>\n

3. Regex DoS nei Numeric Character References<\/h3>\n

Un’espressione regolare mal costruita nella gestione dei numeric character references<\/em> pu\u00f2 essere sfruttata per provocare un Denial of Service<\/em> tramite backtracking catastrofico. Un input appositamente costruito pu\u00f2 bloccare il processo PHP per minuti, rendendo il sito inaccessibile. Identificata da Dennis Snell<\/strong> del WordPress Security Team stesso.<\/p>\n

4. Stored XSS nei Menu di Navigazione<\/h3>\n

Una vulnerabilit\u00e0 di Cross-Site Scripting persistente<\/em> 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\u00e9 i menu sono presenti su tutte le pagine del sito. Scoperta da Phill Savage<\/strong>.<\/p>\n

5. Authorization Bypass in AJAX query-attachments<\/h3>\n

Un bypass dell’autorizzazione nell’handler AJAX query-attachments<\/code> permette a utenti con ruoli bassi di accedere a media e allegati che non dovrebbero poter visualizzare. Segnalata da Vitaly Simonovich<\/strong>.<\/p>\n

6. Stored XSS via data-wp-bind<\/h3>\n

La direttiva data-wp-bind<\/code>, introdotta con l’Interactivity API di WordPress, conteneva una falla che consentiva l’iniezione di script persistenti. Scoperta da kaminuma<\/strong>.<\/p>\n

7. XSS nell’Override dei Template Client-Side<\/h3>\n

Una vulnerabilit\u00e0 XSS che permette di sovrascrivere i template lato client nell’area di amministrazione. Un attaccante pu\u00f2 alterare il rendering dell’interfaccia admin per altri utenti. Scoperta da Asaf Mozes<\/strong>.<\/p>\n

8. Path Traversal in PclZip (CVE-2026-3907)<\/h3>\n

Una vulnerabilit\u00e0 di path traversal<\/em> 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<\/strong> e kaminuma<\/strong>. Questa \u00e8 stata una delle tre patch incomplete in 6.9.2, corretta definitivamente solo nella 6.9.4.<\/p>\n

9. Authorization Bypass nella funzione Notes (CVE-2026-3906)<\/h3>\n

Un bypass dell’autorizzazione nella funzionalit\u00e0 Notes consente ad utenti non autorizzati di accedere o modificare note riservate. Scoperta da kaminuma<\/strong>. Anche questa patch era incompleta in 6.9.2.<\/p>\n

10. XXE nella libreria getID3 (CVE-2026-3908)<\/h3>\n

Una vulnerabilit\u00e0 di XML External Entity<\/em> 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<\/strong> per coordinare la fix. Scoperta da Youssef Achtatal<\/strong>. Terza patch incompleta, chiusa nella 6.9.4.<\/p>\n

Il Caos dei Tre Aggiornamenti in 24 Ore<\/h2>\n

Quello che \u00e8 successo dopo il rilascio della 6.9.2 merita di essere raccontato, perch\u00e9 \u00e8 un caso di studio su come non<\/strong> gestire una security release:<\/p>\n

    \n
  1. 10 marzo, 16:00 UTC<\/strong> \u2014 Rilascio di WordPress 6.9.2 con le 10 fix di sicurezza.<\/li>\n
  2. 10 marzo, ~21:00 UTC<\/strong> \u2014 Report di siti che mostrano white screen of death<\/em>. 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<\/strong>.<\/li>\n
  3. 11 marzo, 22:00 UTC<\/strong> \u2014 Il Security Team scopre che tre delle dieci patch non erano state applicate completamente<\/strong>: PclZip path traversal (CVE-2026-3907), Notes authorization bypass (CVE-2026-3906) e XXE in getID3 (CVE-2026-3908). Rilascio della 6.9.4<\/strong>.<\/li>\n<\/ol>\n

    Nella mia esperienza, questo \u00e8 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\u00e0 di aggiornamento \u00e8 fondamentale. Nel mio caso, come vi racconto nel mio articolo sulla protezione WordPress con virtual patching e WAF<\/a>, utilizzo Patchstack come prima linea di difesa proprio per coprire la finestra temporale tra disclosure e aggiornamento.<\/p>\n

    Come Aggiorno a WordPress 6.9.4 in Sicurezza<\/h2>\n

    Vi mostro la procedura che seguo sui miei server Plesk per aggiornare WordPress in modo sicuro. L’obiettivo \u00e8 arrivare direttamente alla 6.9.4<\/strong> (che include tutte le fix complete), saltando le versioni intermedie problematiche.<\/p>\n

    Step 1: Backup Completo<\/h3>\n

    Prima di qualsiasi aggiornamento, eseguo sempre un backup completo. Come ho spiegato nel mio articolo sui backup automatici su Plesk con destinazione S3<\/a>, avere un backup incrementale recente \u00e8 la prima regola:<\/p>\n

    # Backup del database\nmariadb-dump -u admin -p$(cat \/etc\/psa\/.psa.shadow) wp_dxdqe > \/root\/backup_wp_pre694_$(date +%Y%m%d).sql\n\n# Backup dei file WordPress\ntar czf \/root\/backup_wp_files_pre694_$(date +%Y%m%d).tar.gz \/var\/www\/vhosts\/darioiannascoli.it\/httpdocs\/blog\/<\/code><\/pre>\n
    Step 2: Verifico la Versione Attuale<\/h3>\n
    # Con WP-CLI su Plesk\n\/opt\/plesk\/php\/8.3\/bin\/php \/usr\/local\/bin\/wp core version --path=\/var\/www\/vhosts\/darioiannascoli.it\/httpdocs\/blog --allow-root\n\n# Controllo aggiornamenti disponibili\n\/opt\/plesk\/php\/8.3\/bin\/php \/usr\/local\/bin\/wp core check-update --path=\/var\/www\/vhosts\/darioiannascoli.it\/httpdocs\/blog --allow-root<\/code><\/pre>\n
    Step 3: Aggiornamento<\/h3>\n
    # Aggiorno direttamente alla 6.9.4\n\/opt\/plesk\/php\/8.3\/bin\/php \/usr\/local\/bin\/wp core update --path=\/var\/www\/vhosts\/darioiannascoli.it\/httpdocs\/blog --allow-root\n\n# Verifico la versione installata\n\/opt\/plesk\/php\/8.3\/bin\/php \/usr\/local\/bin\/wp core version --path=\/var\/www\/vhosts\/darioiannascoli.it\/httpdocs\/blog --allow-root<\/code><\/pre>\n
    Step 4: Aggiorno il Database<\/h3>\n
    \/opt\/plesk\/php\/8.3\/bin\/php \/usr\/local\/bin\/wp core update-db --path=\/var\/www\/vhosts\/darioiannascoli.it\/httpdocs\/blog --allow-root<\/code><\/pre>\n
    Step 5: Verifico il Funzionamento<\/h3>\n
    Dopo l’aggiornamento, controllo sempre:<\/p>\n