WordPress 7.0.4 corregge una falla in Imagick che consente agli autori di eseguire codice

WordPress 7.0.4 corregge una falla che consentiva a un autore autenticato di trasformare il caricamento di un'immagine dall'aspetto ordinario in codice in esecuzione sul server. Patchstack, la società di sicurezza che ha segnalato il problema, ha pubblicato il suo resoconto il 12 agosto 2026 e afferma che il problema riguarda le versioni core di WordPress dalla 4.7 alla 7.0. WordPress.org ha pubblicato il proprio annuncio del rilascio. Patchstack afferma inoltre di aver implementato una regola di mitigazione per i siti web interessati collegati alla sua piattaforma.

WordPress si affida a ImageMagick, un toolkit di elaborazione delle immagini ampiamente utilizzato a cui accede tramite un'estensione PHP chiamata Imagick, per ridimensionare ed elaborare le immagini nella Libreria multimediale. Il problema è che ImageMagick comprende molto più di immagini JPEG e PNG. Può anche aprire file PostScript, EPS e PDF e, per visualizzare questi formati, chiama Ghostscript, un programma separato con una lunga storia di essere indotto a eseguire comandi che non dovrebbe. Patchstack colloca questo nella stessa famiglia di problemi dei vecchi bug ImageTragick.

La discrepanza che ha creato il rischio dipende da come ciascuna parte decide cos'è un file. ImageMagick identifica un file dal suo contenuto, mentre WordPress si fidava principalmente dell'estensione del nome del file. Un file chiamato holiday.png che in realtà conteneva PostScript avrebbe quindi superato i controlli di caricamento ed essere passato a Imagick, che avrebbe riconosciuto il PostScript al suo interno e avviato Ghostscript. L'immagine non era mai stata un'immagine.

Patchstack individua la falla nel metodo load() in WP_Image_Editor_Imagick, la parte di WordPress che consegna un file caricato alla libreria di immagini. Sceglieva come passare il file solo in base all'estensione e non guardava mai dentro il file. Le chiamate readImage() e readImageBlob() utilizzate lì ispezionano i byte identificativi del file, i cosiddetti magic bytes, e ignorano il nome. Un contenuto che inizia con %!, \x04%!, \xC5\xD0\xD3\xC6 o \xFFWPC è sufficiente per selezionare la gestione di PostScript, EPS o WordPerfect graphics di ImageMagick, e da lì Ghostscript esegue il file come programma PostScript.

In un caricamento ordinario, il controllo wp_check_filetype_and_ext() di WordPress intercetta questo e ferma l'attacco. Il problema è che non tutti i percorsi di caricamento passano attraverso quel controllo. Patchstack afferma che il metodo wp.uploadFile di XML-RPC e la routine che WordPress usa per estrarre la copertina dai file MP3 caricati scrivono entrambi i loro byte su disco con wp_upload_bits(), una funzione che non ispeziona mai il contenuto. Il payload atterra comunque sul server e raggiunge comunque il codice vulnerabile.

La correzione è un commit numerato 7daaa50, che rielabora la funzione load() in modo che ispezioni il contenuto del file prima di costruire l'oggetto Imagick. Nulla che verrebbe indirizzato a un decoder della famiglia PostScript viene più passato avanti.

Concretamente, il codice corretto annusa il primo blocco di ogni file e respinge diverse categorie. PostScript ed EPS vengono rifiutati sia che vengano individuati dalle loro firme (il marcatore %!, le intestazioni EPS binarie o WordPerfect graphics), sia dall'estensione, sia dai prefissi degli specificatori di formato di ImageMagick. I file che dichiarano un'estensione PDF ma non iniziano con il vero marcatore %PDF- vengono rifiutati come PDF falsi. Anche i file compressi che ImageMagick decomprimerebbe silenziosamente, come gli archivi gzip e bzip2, vengono rifiutati, poiché erano un altro modo per contrabbandare contenuti oltre i controlli.

C'è un dettaglio più sottile. ImageMagick consente di forzare un gestore particolare anteponendo un prefisso a un nome file, ad esempio EPS:innocent.png. Il nuovo codice rimuove e ispeziona quei prefissi, facendo attenzione a non inciampare nelle lettere di unità di Windows come C:. Lo stesso trucco può arrivare tramite un URL remoto o uno stream, quindi la correzione analizza anche i nomi file da quelle fonti prima di convalidarli.

Raggiungere il codice vulnerabile richiede la capacità di caricare media, il che significa un account di livello Autore o superiore. Patchstack è esplicito sul fatto che non si tratta di un attacco anonimo e opportunistico. Ma l'asticella è più bassa di quanto sembri su una pubblicazione con più autori, un sito di membership, un sito cliente con collaboratori o qualsiasi sito con registrazione aperta o gestita in modo lasco. Su quei siti, un autore che carica un'immagine imbottita di trappole è una minaccia realistica piuttosto che teorica. Dove un sito ha solo il suo proprietario e un piccolo gruppo di editori strettamente controllato, l'esposizione è minore.

Aggiornamento. I siti con aggiornamenti automatici in background abilitati potrebbero essere già coperti, quindi vale la pena un rapido controllo della versione, e chi aggiorna manualmente dovrebbe dare priorità a questo rilascio, specialmente dove gli account vengono distribuiti oltre un team ristretto. Per i proprietari di siti che preferirebbero non tenere traccia di ogni rilascio core da soli, AEU Hosting offre hosting WordPress gestito, dove il lato piattaforma della gestione di un sito WordPress viene curato per te.

Patchstack chiude con un promemoria su come viene affrontata la gestione dei media in generale: la parte rischiosa di solito non è l'immagine stessa, ma tutto il resto che la libreria di immagini è silenziosamente disposta ad aprire.