WordPress 7.1.3, uscito il 6 ottobre 2026, corregge sette vulnerabilità. Una riguarda gli embed di Imgur, e l’aggiornamento da solo non la chiude del tutto: secondo l’analisi di Patchstack la patch non cancella gli embed già salvati in cache, quindi un embed malevolo finito nel database prima dell’update continua a essere mostrato. Il sito risulta aggiornato, la dashboard è verde, e l’HTML a rischio è ancora lì.

Il rimedio sono due query e un comando WP-CLI. Qui sotto la sequenza, con il controllo che dimostra che la pulizia è avvenuta davvero.

Perché aggiornare WordPress non basta questa volta

Quando incolli un link Imgur in un articolo, WordPress chiede al servizio l’HTML dell’embed tramite oEmbed. Per i provider non fidati quell’HTML passa da un filtro che lo riduce a un iframe isolato. Imgur stava nella lista dei provider fidati, che saltano il filtro: la risposta dell’API, che include testo scritto da chi ha caricato l’immagine o l’album, finiva nella pagina così com’era. È la vulnerabilità che l’annuncio ufficiale elenca come «Imgur embeds are vulnerable to XSS».

La correzione toglie Imgur dai provider fidati. Ma WordPress non chiede l’embed a ogni visita: lo salva. Per gli embed dentro un articolo la copia sta nei metadati del post, in chiavi che iniziano con _oembed_; per gli embed fuori da un post esiste un tipo di contenuto dedicato, oembed_cache. Patchstack lo scrive in chiaro: la 7.1.3 non rimuove nessuna delle due copie, e un embed malevolo già in cache continua a essere servito.

Se non hai mai incorporato Imgur non hai niente da pulire. Se gestisci un blog o il sito di un cliente dove qualcuno ha incollato quei link negli anni, devi controllare.

Passo 1: conferma la versione, non la notifica

Gli aggiornamenti automatici delle versioni minori sono attivi di default, ma la documentazione ufficiale elenca le costanti che li spengono: AUTOMATIC_UPDATER_DISABLED li blocca tutti, WP_AUTO_UPDATE_CORE impostata a false blocca quelli del core. Le trovo spesso nei siti passati da un vecchio hosting o da uno sviluppatore che voleva «controllare lui». Dalla root del sito:

wp core version
wp core check-update --minor --force-check
wp config get WP_AUTO_UPDATE_CORE
wp config get AUTOMATIC_UPDATER_DISABLED

La prima riga deve stampare 7.1.3. --force-check salta la cache dei controlli e interroga WordPress.org adesso. Se wp config get risponde con un errore, la costante non è definita, ed è il caso buono. Se il sito gira su un ramo vecchio, attenzione: l’annuncio ufficiale dice che le correzioni vengono riportate fino al ramo 4.7, ma «man mano che sono pronte»; al 6 ottobre, scrive Patchstack, erano uscite almeno fino ai rilasci 6.6, mentre i rami dal 4.7 al 6.5 aspettavano ancora la patch. Solo l’ultima versione è supportata attivamente.

Passo 2: trova gli embed Imgur in cache e svuotali

Prima di cercare Imgur conta tutte le cache oEmbed. Se questo numero è zero, anche la ricerca successiva darà zero, e quello zero non dimostra niente:

P=$(wp db prefix)
wp db query "SELECT COUNT(*) FROM ${P}postmeta WHERE meta_key LIKE '_oembed_%'" --skip-column-names
wp db query "SELECT DISTINCT post_id FROM ${P}postmeta WHERE meta_key LIKE '_oembed_%' AND meta_value LIKE '%imgur%'" --skip-column-names

La seconda query elenca gli ID degli articoli con un embed Imgur in cache, uno per riga. Svuotali con il comando documentato di WP-CLI, che accetta un ID alla volta:

wp db query "SELECT DISTINCT post_id FROM ${P}postmeta WHERE meta_key LIKE '_oembed_%' AND meta_value LIKE '%imgur%'" --skip-column-names | xargs -r -n1 wp embed cache clear
wp db query "SELECT ID FROM ${P}posts WHERE post_type = 'oembed_cache' AND post_content LIKE '%imgur%'" --skip-column-names | xargs -r -n1 wp post delete --force

La seconda riga elimina le copie salvate fuori dagli articoli: sono solo cache, WordPress le ricrea alla prossima richiesta, stavolta passando dal filtro. Poi rilancia la query con LIKE '%imgur%': deve restituire zero righe. Il conteggio generale scende anche lui, perché il comando svuota tutte le cache oEmbed di quell’articolo: WordPress le ricrea alla prima visita. Infine svuota la cache di pagina, del plugin o dell’hosting: le pagine già generate contengono l’embed vecchio e non lo sanno.

L’errore da evitare: confondere aggiornato con pulito

Una patch cambia il codice che produce l’output. Non tocca quello che il sito ha già salvato con il codice vecchio: cache, metadati, contenuti generati. Il controllo della dashboard ti dice che il codice è nuovo, non che il database è sano.

Sulle priorità serve misura. Patchstack la definisce una release da installare appena puoi, non un’emergenza da mollare tutto: delle sette correzioni, solo due partono da un visitatore senza account, la lettura dei commenti di articoli privati o non pubblicati e l’XSS nei commenti in attesa, che richiede anche il clic di un moderatore. Tre richiedono un account da Contributor o Author, una un amministratore che lanci un export, l’ultima dipende dai plugin installati. Aggiorna oggi, fai la pulizia degli embed nello stesso giro e prima di lanciare comandi che cancellano righe controlla di essere sul sito giusto: ho scritto qui la guardia che uso negli script WP-CLI.

La mia regola, che vale oltre Imgur: quando leggi le note di una security release cerca una frase sola, «does not remove any existing». Se c’è, l’aggiornamento è metà del lavoro. È lo stesso principio per cui la patch va installata prima di aspettare il WAF: la protezione conta solo quando copre anche quello che è già sul sito.