El fitxer es deia foto.png. Acabava en .png, es presentava com a imatge i va acabar a mans del processador d'imatges sense que saltés res. Ningú no va mentir sobre el nom. El que hi havia a dins era una altra cosa: un programa. Això és el que WordPress va arreglar el 12 d'agost amb la versió 7.0.4, i el que fa el cas interessant és la pregunta que deixa oberta: qui decideix què és un fitxer.
No fem webs de WordPress ni vivim de vendre plugins. Sí que administrem els servidors on viuen webs de clients, i per això aquest avís ens interessa per un lloc diferent de l'habitual: no per WordPress, sinó pel que diu de qualsevol aplicació teva que accepti que algú li pugi un fitxer.
Què es va publicar, i quan
WordPress 7.0.4 va sortir el 12 d'agost del 2026 com a versió exclusivament de seguretat, amb un únic arranjament. L'avís ho descriu sense embuts: «Authenticated Author+ remote code execution via malicious file upload on sites that use Imagick and Ghostscript», i agraeix el report responsable a l'equip de pwn.ai. Es registra com a CVE-2026-65640 i com a GHSA-8vr3-7mxf-gx8w.
La frase que millor mesura la mida de l'assumpte és a la nota de la mateixa release: l'arranjament s'ha portat enrere «fins a la branca 4.7», i també a la 7.1 RC3. WordPress 4.7 es va publicar el 6 de desembre del 2016. El codi que avui es corregeix fa gairebé deu anys que funciona exactament igual, en totes les branques intermèdies, sense que ningú mirés allà.
Que el backport s'aturi justament a la 4.7 té una explicació que cap cobertura no ha posat, i la donem com a lectura nostra i no com a declaració del projecte: la 4.7 és la versió que va estrenar les miniatures de PDF a la biblioteca de mèdia —«ara mostra miniatures de vista prèvia en lloc d'una icona genèrica per als PDF», diu la seva documentació—, i generar la miniatura d'un PDF és justament el que obliga WordPress a demanar a Imagick que cridi Ghostscript. El camí que es tanca avui es va obrir el dia que es va estrenar aquesta funció.
Un dia després, el 13 d'agost, INCIBE-CERT ho va recollir com a INCIBE-2026-552 amb severitat alta i una descripció que assenyala el lloc exacte: «Ghostscript no maneja de forma segura ciertos archivos incrustados. Un atacante con la capacidad upload_files podría subir un archivo Postscript malicioso, lo que puede resultar en una ejecución remota de código». Guarda aquesta paraula, upload_files: és la que decideix si això va amb tu, i hi tornem més avall.
Tres programes, tres opinions sobre el mateix fitxer
Un fitxer pujat a una web passa per diverses mans abans de convertir-se en la miniatura que veu el visitant, i cadascuna se'l mira d'una manera diferent:
- 1WordPress mira com es diu i què diu que és, si el fitxer entra per una ruta que no ensuma el contingut. Extensió permesa, tipus declarat correcte: endavant.
- 2ImageMagick no llegeix el nom: llegeix els primers bytes. I allà troba la signatura de PostScript, així que decideix —correctament, segons les seves normes— que allò no és un PNG.
- 3Ghostscript, a qui ImageMagick delega el PostScript, fa la seva feina: PostScript és un llenguatge de programació complet, i el que fa un intèrpret amb un programa és executar-lo.
Cap dels tres s'equivoca pel seu compte. El problema és que l'opinió que compta és sempre la de l'últim de la cadena, i el primer és qui fa de porter. Validar l'extensió és preguntar al fitxer com es diu. És el mateix patró del qual vam escriure amb Tomcat fa uns dies: un control que existeix, que s'executa i que tot i així deixa passar, perquè comprova una cosa diferent de la que fa mal.
Hi ha un matís que la majoria de cobertures s'estalvia i que convé dir, encara que espatlli la simetria del conte: en la pujada normal de la biblioteca de mèdia, WordPress sí que mira a dins. La funció wp_check_filetype_and_ext() compara el tipus real amb l'extensió i llença el fitxer si no quadren. El que passa és que no totes les rutes de pujada hi passen: segons l'anàlisi de Cyber Security News, el mètode wp.uploadFile d'XML-RPC i l'extracció de caràtules dels MP3 escriuen els bytes directament amb wp_upload_bits(), que se salta la inspecció de contingut. Amb que una porta lateral no pregunti, el porter de la principal deixa de comptar.
El pedaç mou la comprovació al lloc correcte. El commit porta un títol que resumeix l'arranjament sencer —«Media: Prevent loading images into Imagick which might be PostScript»— i toca WP_Image_Editor_Imagick::load() per mirar el contingut abans de construir l'objecte Imagick: rebutja extensions de PostScript, rebutja les signatures binàries que identifiquen un EPS o un PS, exigeix que un PDF comenci de debò per %PDF- i rebutja els fitxers comprimits que Imagick descomprimiria pel seu compte. És a dir: WordPress deixa de refiar-se del nom també en aquest camí i passa a mirar a dins, que és el que feia el programa del costat.
Dues condicions, i la primera no la decideixes tu
Perquè això sigui explotable a la teva web s'han de donar les dues alhora. La primera és de servidor: que el processament d'imatges faci servir Imagick i que a més hi hagi Ghostscript instal·lat. Moltes instal·lacions fan servir la biblioteca GD, i allà no hi ha delegació possible ni, per tant, aquest camí. El que és incòmode és qui pren aquesta decisió: no la pren el teu tema, ni el teu plugin de galeries, ni qui escriu els articles. La pren qui va muntar el servidor o la imatge del contenidor, probablement fa anys, i no t'ho va consultar.
La bona notícia és que es comprova sense tocar cap consola: Eines → Salut del lloc → Informació → gestió de mèdia (Media Handling). WordPress t'hi diu quina versió d'ImageMagick té al davant i quina versió de Ghostscript hi ha al darrere. Si la segona no hi surt, respira.
Convé dir una cosa que no afavoreix el relat: bona part de qui se n'ha salvat, se n'ha salvat per una decisió que no va prendre. El policy.xml que distribueix ImageMagick ve obert a propòsit —ho diu el projecte mateix: està pensat per a entorns controlats—, però després de la ratxa de fallades de Ghostscript del 2018 diverses distribucions, Debian i Ubuntu entre elles, van començar a empaquetar el seu propi policy.xml amb els coders PS, EPS, PDF i XPS a rights="none", precisament perquè cridar Ghostscript va deixar de considerar-se segur. Qui tingui aquesta política posada feia anys que tenia aquest camí tancat sense saber-ho. És una defensa real, però convé dir-ne el nom: no va ser previsió teva, va ser herència.
Qui té la clau de pujar fitxers
La segona condició és el compte. Cal un amb la capacitat upload_files, que en una instal·lació per defecte tenen Autor, Editor i Administrador —el rol Col·laborador no pot pujar fitxers—. Quan un avís diu «requereix autenticació», molta gent ho llegeix com si digués «requereix ser tu». En un gestor de continguts no vol dir això. Vol dir requereix un compte dels que es regalen.
Pensa en la web corporativa real, no en la ideal. L'agència que la va muntar el 2019 encara té el seu usuari. La persona de màrqueting que pujava les notes de premsa va canviar d'empresa al març. El becari de l'estiu passat no es va donar mai de baixa. Hi ha un plugin de subscripcions que assigna Autor a qui es registra, perquè així venia configurat. I hi ha un usuari anomenat redaccio la contrasenya del qual coneixen quatre persones, tres de les quals ja no hi treballen. Cap d'aquests comptes no el va crear cap atacant: els vam crear nosaltres, un a un, amb un motiu raonable cada vegada.
Deu minuts per saber si et toca
- ✓Quina versió corres de debò.
wp core version, o el tauler. Les branques mantingudes van rebre la seva correcció: 7.0.4, 6.9.7, 6.8.8 i així cap enrere. Si ets en una branca vella i no l'actualitzes, aquí no hi ha terme mitjà. - ✓Si el teu servidor té les dues peces. Sense consola: Salut del lloc → Informació → gestió de mèdia. Amb consola:
php -m | grep -i imagickigs --version. - ✓Què diu la teva política d'ImageMagick.
convert -list policya ImageMagick 6,magick -list policya la 7. Busca els coders PS, EPS, PDF i XPS ambrights="none". Si hi són, tens una segona barrera que no depèn de la versió de WordPress —però no és una porta tancada: el mateix equip que va reportar aquesta fallada va publicar el març del 2026 diverses maneres d'esquivar aquesta política, entre elles que el mòdul PDF acaba cridant el mateix delegat—. - ✓Qui pot pujar fitxers.
wp user list --fields=user_login,roles,user_registeredi llegeix la llista sencera, no per sobre. Cada Autor, Editor i Administrador és una clau. Les que no reconeguis, primer abaixa-les a un rol senseupload_filesi esborra-les quan sàpigues què hi penja: esborrar un usuari a WordPress obliga a decidir si el seu contingut s'esborra o es reassigna, i és allà on es despubliquen articles sense voler. - ✓Si el registre obert reparteix permisos. Mira el rol per defecte a Configuració → General i el que assigni qualsevol plugin de subscripcions o de formularis. Un registre públic que dona Autor converteix «requereix autenticació» en «no requereix res».
- ✓Què hi ha a la carpeta de pujades. Fitxers recents que no encaixen amb cap contingut publicat,
.phpon només hi hauria d'haver mèdia, imatges amb dates estranyes. No és una anàlisi forense, però és la mirada que gairebé ningú fa. I si hi apareix alguna cosa, tingues present que actualitzar no ho treu: el pedaç tanca la porta, no neteja la casa.
El que no faríem
Tres reflexos comuns que surten cars:
- ✕Desinstal·lar Imagick per si de cas. És la reacció ràpida i trenca coses: WordPress cau a GD, canvien els retalls i la qualitat de les miniatures, i es perd el processament de formats que potser fa servir la teva botiga. Si has de treure alguna cosa, treu el coder concret a la política, no la biblioteca sencera.
- ✕Esperar que el CVE tingui nota per decidir. A dia d'avui CVE-2026-65640 continua reservat al NVD i les cobertures manegen un 8,8 sense autoritat primària al darrere. La teva urgència no la fixa aquesta xifra: la fixen les teves dues condicions. Amb registre obert i rol Autor per defecte, això és pitjor que qualsevol nota. Sense Ghostscript, és un zero.
- ✕Deixar les actualitzacions menors desactivades «per estabilitat». És la conversa que ja vam tenir amb la fallada del juliol: els llocs amb l'actualització automàtica posada es van corregir sols de matinada, i les «gestionades» amb les actualitzacions apagades van esperar que algú se'n recordés dilluns.
A dia d'avui no hi ha constància pública d'explotació d'aquesta fallada. Ahir mateix vam explicar fins on val aquesta frase: a l'avís de vCenter va durar cinc dies. Serveix per ordenar la cua, no per dormir tranquil. Amb Ghostscript instal·lat i comptes d'Autor repartits, això és d'aquesta tarda.
Si només t'endús una cosa
Actualitza a la versió corregida de la teva branca, mira si tens Ghostscript al darrere i neteja la llista de gent que pot pujar fitxers. Això resol el cas concret. El que no es resol actualitzant és l'altre: la teva web crida biblioteques que criden intèrprets que tu no vas triar mai —el mateix problema que vam explicar amb la biblioteca que ningú va triar a Rails—, i cadascuna té la seva pròpia idea de què és el fitxer que li acabes de passar. Per això la pregunta que deixa aquest avís no és «estic a la 7.0.4?», sinó aquesta altra: quants comptes de la teva web poden pujar un fitxer, i quan va ser l'última vegada que algú va llegir aquesta llista sencera?
Fonts (consultades el 14 d'agost del 2026): data de la versió, descripció de la fallada, crèdit a pwn.ai, referències CVE-2026-65640 i GHSA-8vr3-7mxf-gx8w i abast del backport fins a la branca 4.7 — nota de la release WordPress 7.0.4; data de publicació de WordPress 4.7 i la funció de miniatures de PDF que va estrenar — documentació de la versió 4.7 (la relació entre totes dues coses és lectura nostra, no una declaració del projecte); severitat, identificador, versions corregides per branca i descripció de la capacitat upload_files — avís INCIBE-2026-552 de l'INCIBE-CERT (la citació va en el seu castellà original); contingut de l'arranjament a WP_Image_Editor_Imagick::load() — commit 7daaa50 de wordpress-develop; rutes de pujada que no inspeccionen el contingut (XML-RPC i wp_upload_bits()) — anàlisi de Cyber Security News; caràcter deliberadament obert de la política que distribueix el projecte — política de seguretat d'ImageMagick; maneres d'esquivar les restriccions de coders, publicades el març del 2026 pel mateix equip que va reportar aquesta fallada — recerca de pwn.ai. Ni WordPress ni l'INCIBE han publicat informació sobre explotació en curs; qualsevol afirmació sobre campanyes concretes avui seria especulació. Foto: «Alphabet letterpress», domini públic (CC0), via Openverse (rawpixel).
Qui mira les aplicacions que publiques a Internet?
A everyWAN treballem les dades i les aplicacions amb la mateixa exigència que la infraestructura que hi ha a sota: qui entra, amb quin permís i quines biblioteques corren al darrere. Les mirem amb els mateixos ulls amb què mirem un tallafoc, perquè en ciberseguretat l'inventari del que corre en un servidor inclou també allò que l'aplicació crida sense dir-t'ho.
Parlar amb everyWAN
Microsoft 365
ES 
CAT 
EN