WordPress 7.1.1: le 11 falle di sicurezza corrette e perché aggiornare subito

Di Daniele Forciniti

Indice del Contenuto

WordPress 7.1.1 è l’aggiornamento di sicurezza e manutenzione uscito il 17 settembre 2026: corregge 11 vulnerabilità, 17 bug del core e 19 dell’editor a blocchi. La più seria permette a un visitatore qualunque, senza account e senza password, di lasciare un commento che contiene codice, codice che poi finisce nella pagina e parte nel browser di chi la apre. Va installato subito, e se hai gli aggiornamenti automatici attivi con ogni probabilità ce l’hai già.

Le altre dieci falle richiedono un account sul sito, ma tre bastano i permessi più bassi che esistano, quelli del collaboratore, e una funziona con qualsiasi utente registrato. In questo articolo le trovi tutte e undici spiegate una per una, con chi le ha segnalate, quanto sono gravi davvero, come capire se qualcuno ci ha già provato sul tuo sito e come aggiornare senza rompere niente.

Perché questa volta conviene muoversi in fretta

Gli aggiornamenti minori di WordPress escono spesso e quasi sempre riguardano problemi che un attaccante può sfruttare solo se ha già un piede dentro il sito. Questa volta no. La falla principale, registrata come CVE-2026-93485 con punteggio CVSS 7.1, è la barriera d’ingresso più bassa dell’intero pacchetto: non serve nessun account, basta il modulo dei commenti aperto al pubblico.

C’è una condizione che smorza un po’ l’allarme: il commento deve essere pubblicato, quindi in genere passa dalla moderazione. Ma attenzione a come è configurato il tuo sito, perché WordPress ha di serie l’opzione che approva in automatico chi ha già avuto un commento approvato in passato. Se quell’opzione è attiva, e nella maggior parte dei siti lo è, basta che l’attaccante lasci prima un commento innocuo, aspetti il tuo via libera, e da quel momento pubblica da solo.

Tradotto in pratica: se hai un blog con i commenti aperti, questa è la correzione che conta più delle altre dieci messe insieme. Se i commenti li hai chiusi ovunque, puoi respirare, ma non saltare l’aggiornamento lo stesso, perché le altre falle toccano i permessi degli utenti e chi ha un sito con più redattori è comunque esposto.

Cosa è andato storto dentro wpautop, spiegato semplice

Qui la parte tecnica vale la pena di raccontarla, perché spiega una cosa che tanti non si aspettano: il contenuto può essere pulito quando lo salvi e diventare pericoloso quando lo mostri.

wpautop() è la funzione che trasforma gli a capo in paragrafi. È quella che fa sì che tu scriva due righe separate da un invio e in pagina esca due <p>. Gira praticamente su ogni contenuto che WordPress stampa, articoli e commenti compresi. Per fare il suo lavoro sostituisce temporaneamente gli a capo con dei commenti HTML, poi rimette tutto a posto.

Il problema stava in una espressione regolare che cercava i tag usando il pezzo ([^>]*), cioè “prendi tutto fino al primo maggiore”. Quel modo di cercare non tiene conto degli attributi tra virgolette: se dentro un attributo finisce un carattere >, e i commenti inseriti dalla funzione ne generano, il tag viene spezzato nel punto sbagliato e quello che era testo innocuo diventa markup vero.

È per questo che il filtro di pulizia dei commenti, wp_kses(), non lo fermava: al momento del salvataggio quella stringa non sembra pericolosa, non contiene un tag vietato, contiene solo testo dentro un attributo. Diventa uno script soltanto dopo, durante la formattazione in uscita. Nei miei anni passati a sistemare siti bucati ho visto parecchie volte questo schema, il controllo fatto in un punto e il danno che nasce in un altro, ed è il tipo di bug più fastidioso da trovare a mano.

Le undici falle corrette, una per una

L’annuncio ufficiale le elenca in ordine sparso e senza spiegarle. Le ho messe in ordine di quanto è facile sfruttarle, con la traduzione in italiano di cosa vuol dire per chi ha un sito.

Cosa permette di fare	Serve essere	Chi l’ha segnalata
Iniettare script tramite i commenti, sfruttando la formattazione dei paragrafi	Nessun account, solo il commento approvato	Rafie Muhammad (Awesome Motive)
Spostare i commenti, note comprese, sotto un altro contenuto	Qualsiasi utente registrato	viridis
Leggere il titolo di un articolo privato attraverso i dati di un allegato	Utente registrato con accesso ai media	HDWSec
Sovrascrivere articoli altrui	Collaboratore o superiore	Anthropic
Uscire dalle cartelle previste nel controller dei template dell’API REST	Utente autenticato	Anthropic
Scoprire gli slug di bozze e articoli in attesa di revisione	Collaboratore o superiore	hermanhms
Pubblicare changeset che scavalcano il controllo sul CSS personalizzato, via XML-RPC	Autore o superiore	Ben Bidner (team sicurezza WordPress)
Iniettare script nelle immagini di intestazione di alcuni temi	Chi gestisce l’aspetto del tema	Jeremy Felt (team sicurezza WordPress)
Installare e mettere in anteprima un tema di WordPress.org con un URL costruito ad arte	Amministratore che apre il link	Paulos Yibelo e pwn.ai
Attivare su tutta la rete un plugin riservato alla rete	Amministratore di un sito in multisito	Jesse McNeil
Far uscire il testo da un commento HTML nell’API HTML	Dipende da come tema e plugin usano l’API	Jeremy Felt (team sicurezza WordPress)

Tre meritano due righe in più. La sovrascrittura degli articoli è quella che in un sito con più autori fa più danni: il ruolo collaboratore è quello che si dà a chi scrive ma non pubblica, e in teoria non può toccare il lavoro degli altri. Il path traversal nell’API REST riguarda il controller dei template, cioè la parte che serve i file del tema a blocchi: uscire dalla cartella prevista significa leggere file che non dovresti vedere. Lo spostamento dei commenti sembra una sciocchezza, ma le note interne in WordPress sono commenti a tutti gli effetti, e spostarle significa farle comparire dove non dovrebbero.

Grafico: quale livello di accesso serve per sfruttare le 11 vulnerabilità corrette dalla 7.1.1 — Una sola falla su undici non richiede alcun account, ed è quella dei commenti.

Due segnalazioni su undici arrivano da Anthropic

Questa è la parte che nessuno racconta e che secondo me conta più della singola patch. Due delle undici falle, la sovrascrittura degli articoli e il path traversal nell’API REST, sono accreditate ad Anthropic, l’azienda che sviluppa Claude. Una terza, quella del tema installato tramite URL, arriva da pwn.ai insieme al ricercatore Paulos Yibelo.

Non è un caso isolato. Come ha ricostruito The Repository, da luglio ogni singola uscita di sicurezza di WordPress cita aziende di intelligenza artificiale, o come segnalatori o per l’uso dei loro modelli nella scoperta. L’uscita d’emergenza 7.0.2 ha chiuso una falla critica sfruttabile senza autenticazione, trovata da un ricercatore che si era appoggiato a un modello di OpenAI. La 7.0.3 ne ha corrette dodici citando Anthropic, pwn.ai e Aikido Security. La 7.0.4, una settimana dopo, un’altra esecuzione di codice.

I numeri dicono tutto: le segnalazioni al programma HackerOne di WordPress sono passate da una media di 20-30 al mese, stabile per dieci anni, a 773 nel solo mese di agosto. Il primo settembre il progetto ha formalizzato una iniziativa dedicata alla sicurezza del core e ha alzato l’asticella per accettare le segnalazioni di gravità bassa, semplicemente perché il team non riusciva più a starci dietro.

Per chi ha un sito il significato è concreto e va detto chiaro: le falle non stanno aumentando, sta aumentando la velocità con cui vengono trovate. Erano lì anche prima, in alcuni casi da anni. La conseguenza è che gli aggiornamenti di sicurezza usciranno più spesso di quanto siamo abituati, e chi aggiorna una volta ogni tanto resterà scoperto più a lungo di prima. Chi trova le falle oggi usa strumenti automatici: è ragionevole aspettarsi che anche chi le sfrutta faccia lo stesso.

Come aggiornare a WordPress 7.1.1 senza rompere niente

Il percorso normale è quello dalla bacheca: Aggiornamenti, poi Aggiorna adesso. Prima di cliccare, però, ci sono quattro cose che faccio sempre e che in dieci anni mi hanno evitato un mucchio di serate storte.

Un backup che sai ripristinare. Database e file, e soprattutto la certezza di saperlo rimettere indietro. Un backup mai provato non è un backup, è una speranza.
Aggiorna prima plugin e tema, poi il core. Quasi tutti i problemi dopo un aggiornamento nascono da un plugin rimasto indietro, non dal core.
Se hai un ecommerce o codice su misura, passa dallo staging. Su un negozio la prova non è la homepage: sono carrello, spedizioni, tasse, coupon, pagamento e email di conferma.
Scegli un orario tranquillo. Non il venerdì alle 19, non durante una campagna attiva.

Se lavori da terminale, con WP-CLI l’aggiornamento e la verifica sono tre comandi: wp core update per installare, wp core verify-checksums per controllare che i file del core siano identici a quelli ufficiali (utile anche per scoprire file modificati da qualcun altro) e wp plugin list --update=available per vedere cosa resta indietro.

Sugli aggiornamenti automatici: WordPress installa da solo gli aggiornamenti minori come questo, a meno che qualcuno non li abbia disattivati. Vale la pena controllarlo davvero invece di darlo per scontato, perché capita spesso che un hosting o un plugin di manutenzione li abbia spenti in passato e poi nessuno se ne ricordi. Nella schermata degli aggiornamenti c’è scritto in chiaro se il sito riceve o meno gli aggiornamenti in automatico.

Daniele Forciniti · DF Studio Design

Gli aggiornamenti di sicurezza non aspettano che tu abbia tempo

Con le segnalazioni passate da trenta al mese a quasi ottocento, le patch usciranno sempre più spesso. Il punto non è correre ogni volta: è avere un backup che funziona, uno staging dove provare e qualcuno che guardi il sito quando esce una patch importante.

Mi chiamo Daniele Forciniti: faccio siti web e posizionamento da dieci anni, e da due lavoro anche sulla GEO. Se il tuo sito è in produzione e non hai voglia di pensarci ogni mese, me ne occupo io.

Assistenza WordPress Sviluppo siti WordPress

Come capire se qualcuno ci ha già provato

Questa è la domanda che mi fanno sempre e a cui nessuno degli articoli che ho letto in giro risponde. Nessuno di questi controlli dà una certezza assoluta, ma insieme dicono parecchio e si fanno in un quarto d’ora.

La coda dei commenti. Guarda approvati, in attesa e spam cercando <script, onerror=, onload= e javascript:. Da terminale: wp comment list --search="onerror" --field=comment_ID. Occhio anche ai commenti banali e generici di utenti mai visti, che servono a farsi approvare la prima volta.
Gli utenti. wp user list --role=contributor e --role=author: se compaiono account che non hai creato tu, il problema è più grosso di questa patch.
I temi installati. wp theme list: un tema che non ricordi di aver installato è esattamente il risultato della falla dell’URL costruito ad arte.
I changeset del personalizzatore. wp post list --post_type=customize_changeset --post_status=any: servono a salvare le modifiche del personalizzatore, e una quantità anomala o voci recenti che non corrispondono a modifiche tue vanno guardate.
L’integrità del core. wp core verify-checksums ti dice se un file di WordPress è diverso da quello ufficiale.
I log dell’hosting. Cerca chiamate ripetute a xmlrpc.php: la falla sul CSS personalizzato passa da lì, e se non usi XML-RPC per niente vale la pena chiuderlo del tutto.

Se trovi qualcosa che non torna, aggiorna prima di tutto, poi cambia le password degli amministratori e invalida le sessioni aperte. Un consiglio che do sempre: non cancellare subito le tracce, perché servono a capire da dove è entrato.

E se il sito è fermo a una versione vecchia?

Qui WordPress fa una cosa che pochi progetti fanno: le correzioni sono state portate indietro su tutti i rami ancora idonei, fino alla 4.7 del 2016. Significa che anche un sito rimasto su una versione vecchia ha una patch pronta.

Se il tuo sito è su	Aggiorna a	Falle corrette
7.0	7.0.5	tutte e 11
6.9	6.9.8	tutte e 11
6.8	6.8.9	tutte e 11
6.7	6.7.8	tutte e 11
da 6.6 a 5.9	dalla 6.6.8 alla 5.9.17	10 su 11
da 5.8 a 5.6	dalla 5.8.16 alla 5.6.20	9 su 11
da 5.5 a 5.3	dalla 5.5.21 alla 5.3.24	8 su 11
da 5.2 a 4.8	dalla 5.2.27 alla 4.8.31	7 su 11
4.7	4.7.36	6 su 11
4.6 e precedenti	nessuna patch	non più supportate

Detto questo, il progetto lo ripete a ogni uscita e ha ragione: l’unica versione davvero supportata è l’ultima. La patch su un ramo vecchio è un ponte per prendere tempo, non un posto dove restare a vivere.

Cosa cambia oltre alla sicurezza

Accanto alle undici correzioni ci sono 17 bug risolti nel core e quelli dell’editor a blocchi, dove tra l’altro i conti ufficiali non tornano: l’annuncio parla di 19 correzioni, la pagina di documentazione della versione ne conta 21. Piccola imprecisione, ma dà l’idea di quanto sia stato compresso il lavoro su questa uscita, chiusa da oltre 90 persone in poche settimane.

I file toccati sono tredici, e leggerli è il modo più rapido per capire dove guardare se qualcosa nel tuo sito si comporta in modo strano dopo l’aggiornamento: formatting.php (è lì che vive wpautop), il processore di tag dell’API HTML, il controller dei commenti dell’API REST, il server XML-RPC, la gestione delle immagini di intestazione, theme.php e alcuni file dell’area di amministrazione. Se usi un plugin che filtra i commenti o che manipola l’HTML in uscita, è il punto da controllare per primo.

La prossima versione principale sarà la 7.2, prevista per dicembre.

Cosa ne penso

Da quando seguo siti di clienti, il ritmo delle patch di sicurezza di WordPress non è mai stato questo. Quattro uscite di sicurezza in poche settimane non sono un segnale che WordPress sia diventato meno sicuro, sono il segnale che è finita l’epoca in cui trovare un bug richiedeva settimane di lavoro umano. Un modello che legge il codice fa in un pomeriggio quello che prima richiedeva un ricercatore per mesi, e infatti le segnalazioni sono passate da trenta a settecentosettantatré al mese.

La conclusione pratica che ne traggo, e che dico ai clienti: smettere di pensare all’aggiornamento come a un evento e cominciare a trattarlo come una routine. Aggiornamenti automatici per i minori attivi, backup giornaliero che qualcuno ha provato a ripristinare almeno una volta, staging per i siti che fanno fatturato e una persona che guarda il sito quando esce una patch importante. Chi ha questo in piedi ha letto questa notizia e non ha dovuto fare niente. Chi non ce l’ha, oggi ha una finestra aperta con dentro un commento che aspetta di essere approvato.

Una nota anche sui commenti, visto che è il punto d’ingresso di questa storia: se sul tuo sito i commenti non li legge e non li scrive nessuno da anni, chiuderli è una decisione di sicurezza, non una rinuncia. Meno superficie esposta, meno cose da aggiornare di corsa.

Conclusione

La 7.1.1 è un aggiornamento da fare subito, non da mettere in lista per il mese prossimo. La falla dei commenti è l’unica che si può sfruttare senza avere un account, e in un sito con i commenti aperti è una porta lasciata accostata. Tutte le altre richiedono un utente registrato, ma tre bastano i permessi di un collaboratore, che è il ruolo che si dà con più leggerezza.

Aggiorna dalla bacheca, controlla che gli aggiornamenti automatici siano davvero attivi, e se hai un sito importante fatti dieci minuti di controlli sui commenti e sugli utenti. Poi torna a lavorare, che è quello che conta.

FAQ

Devo aggiornare anche se ho i commenti chiusi?

Sì. Con i commenti chiusi la falla più grave non ti tocca, ma restano dieci correzioni che riguardano permessi, API REST, XML-RPC e temi. Se sul sito ci sono altri utenti oltre a te, alcune di quelle falle sono sfruttabili con i permessi più bassi che esistano.

Come faccio a sapere che versione ho adesso?

Entra in bacheca e guarda in basso a destra nella schermata principale, oppure apri Strumenti e poi Salute del sito, scheda Informazioni. Da terminale è wp core version.

Aggiornando rischio di rompere il sito?

Un aggiornamento minore cambia pochissimo e il rischio è basso: qui sono stati toccati tredici file. I problemi in genere arrivano da plugin o temi vecchi che non erano più compatibili nemmeno prima. Con backup e staging il rischio diventa trascurabile.

Gli aggiornamenti automatici bastano?

Per gli aggiornamenti minori come questo sì, a patto che siano davvero attivi. Non coprono però plugin e temi, se non li hai impostati uno per uno, ed è lì che nasce la maggior parte dei siti compromessi.

Un plugin di sicurezza mi protegge lo stesso?

In parte. Un firewall può bloccare payload noti prima che arrivino al sito, ma la falla resta nel codice finché non aggiorni. Il plugin fa guadagnare tempo, non sostituisce la patch.

Cosa succede se resto sulla 7.0?

La 7.0 è vulnerabile a tutte e undici le falle. Esiste la 7.0.5 che le corregge, quindi almeno quella va installata, ma il ramo vecchio riceve solo le patch di sicurezza e nessuna delle correzioni funzionali.

Perché escono così tanti aggiornamenti di sicurezza ultimamente?

Perché le vulnerabilità vengono trovate molto più in fretta di prima: le segnalazioni al programma bug bounty di WordPress sono passate da 20-30 al mese a 773 ad agosto, con diverse aziende di intelligenza artificiale tra chi segnala. Il codice non è peggiorato, è cambiato chi lo guarda.

Fonti

WordPress.org, 17 settembre 2026: l’annuncio ufficiale con l’elenco delle undici segnalazioni e i crediti.
Documentazione della versione 7.1.1: i file modificati, i rami aggiornati e quante falle riguardano ciascuno.
Patchstack: l’analisi tecnica della falla in wpautop, con CVE e punteggio CVSS.
The Repository, 18 settembre 2026: i crediti alle aziende di AI e i numeri del programma bug bounty.
Make WordPress Core: la release candidate con l’elenco completo dei bug corretti.
Programma HackerOne di WordPress: dove arrivano le segnalazioni di vulnerabilità.

Daniele Forciniti

Sono Daniele Forciniti, un esperto di web design e SEO con oltre 10 anni di esperienza e diverse certificazioni professionali. Mi specializzo in HTML e CSS, utilizzo CMS come WordPress. Sono il maggior esperto in Italia di WIX e WIX Studio, mi occupo anche di SEO posizionamento web nei motori di ricerca e digital marketing. Sono appassionato del mio lavoro e continuo ad aggiornare le mie competenze per fornire soluzioni innovative e di alta qualità ai miei clienti.