El fichero se llamaba foto.png. Terminaba en .png, se presentaba como imagen y acabó en manos del procesador de imágenes sin que saltara nada. Nadie mintió sobre el nombre. Lo que había dentro era otra cosa: un programa. Eso es lo que WordPress arregló el 12 de agosto con la versión 7.0.4, y lo que hace el caso interesante es la pregunta que deja abierta: quién decide qué es un fichero.
No hacemos webs de WordPress ni vivimos de vender plugins. Sí administramos los servidores donde viven webs de clientes, y por eso este aviso nos interesa por un sitio distinto al habitual: no por WordPress, sino por lo que dice de cualquier aplicación tuya que acepte que alguien le suba un fichero.
Qué se publicó, y cuándo
WordPress 7.0.4 salió el 12 de agosto de 2026 como versión exclusivamente de seguridad, con un único arreglo. El aviso lo describe sin rodeos: «Authenticated Author+ remote code execution via malicious file upload on sites that use Imagick and Ghostscript», y agradece el reporte responsable al equipo de pwn.ai. Se registra como CVE-2026-65640 y como GHSA-8vr3-7mxf-gx8w.
La frase que mejor mide el tamaño del asunto está en la nota de la propia release: el arreglo se ha llevado hacia atrás «hasta la rama 4.7», además de a la 7.1 RC3. WordPress 4.7 se publicó el 6 de diciembre de 2016. El código que hoy se corrige lleva casi diez años funcionando exactamente igual, en todas las ramas intermedias, sin que nadie mirara ahí.
Que el backport se pare justo en 4.7 tiene una explicación que ninguna cobertura ha puesto, y la damos como lectura nuestra y no como declaración del proyecto: 4.7 es la versión que estrenó las miniaturas de PDF en la biblioteca de medios —«ahora muestra miniaturas de vista previa en lugar de un icono genérico para los PDF», dice su documentación—, y generar la miniatura de un PDF es justo lo que obliga a WordPress a pedirle a Imagick que llame a Ghostscript. El camino que se cierra hoy se abrió el día que se estrenó esa función.
Un día después, el 13 de agosto, INCIBE-CERT lo recogió como INCIBE-2026-552 con severidad alta y una descripción que apunta al sitio exacto: «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 esa palabra, upload_files: es la que decide si esto va contigo, y volvemos a ella más abajo.
Tres programas, tres opiniones sobre el mismo fichero
Un fichero subido a una web pasa por varias manos antes de convertirse en la miniatura que ve el visitante, y cada una lo mira de una forma distinta:
- 1WordPress mira cómo se llama y qué dice ser, si el fichero entra por una ruta que no huele el contenido. Extensión permitida, tipo declarado correcto: adelante.
- 2ImageMagick no lee el nombre: lee los primeros bytes. Y ahí encuentra la firma de PostScript, así que decide —correctamente, según sus normas— que eso no es un PNG.
- 3Ghostscript, al que ImageMagick delega el PostScript, hace su trabajo: PostScript es un lenguaje de programación completo, y lo que hace un intérprete con un programa es ejecutarlo.
Ninguno de los tres se equivoca por su cuenta. El problema es que la opinión que cuenta es siempre la del último de la cadena, y el primero es el que hace de portero. Validar la extensión es preguntarle al fichero cómo se llama. Es el mismo patrón del que escribimos con Tomcat hace unos días: un control que existe, que se ejecuta y que aun así deja pasar, porque comprueba una cosa distinta de la que hace daño.
Hay un matiz que la mayoría de coberturas se salta y que conviene decir, aunque estropee la simetría del cuento: en la subida normal de la biblioteca de medios, WordPress sí mira dentro. La función wp_check_filetype_and_ext() compara el tipo real con la extensión y tira el fichero si no cuadran. Lo que ocurre es que no todas las rutas de subida pasan por ahí: según el análisis de Cyber Security News, el método wp.uploadFile de XML-RPC y la extracción de carátulas de los MP3 escriben los bytes directamente con wp_upload_bits(), que se salta la inspección de contenido. Con que una puerta lateral no pregunte, el portero de la principal deja de contar.
El parche mueve la comprobación al sitio correcto. El commit lleva un título que resume el arreglo entero —«Media: Prevent loading images into Imagick which might be PostScript»— y toca WP_Image_Editor_Imagick::load() para mirar el contenido antes de construir el objeto Imagick: rechaza extensiones de PostScript, rechaza las firmas binarias que identifican un EPS o un PS, exige que un PDF empiece de verdad por %PDF- y rechaza los ficheros comprimidos que Imagick descomprimiría por su cuenta. Es decir: WordPress deja de fiarse del nombre también en este camino y pasa a mirar dentro, que es lo que hacía el programa de al lado.
Dos condiciones, y la primera no la decides tú
Para que esto sea explotable en tu web tienen que darse las dos a la vez. La primera es de servidor: que el procesado de imágenes use Imagick y que además haya Ghostscript instalado. Muchas instalaciones usan la biblioteca GD, y ahí no hay delegación posible ni, por tanto, este camino. Lo incómodo es quién toma esa decisión: no la toma tu tema, ni tu plugin de galerías, ni el que escribe los artículos. La toma quien montó el servidor o la imagen del contenedor, probablemente hace años, y no te lo consultó.
La buena noticia es que se comprueba sin tocar una consola: Herramientas → Salud del sitio → Información → Gestión de medios (Media Handling). WordPress te dice ahí mismo qué versión de ImageMagick tiene delante y qué versión de Ghostscript hay detrás. Si la segunda no aparece, respira.
Conviene decir algo que no favorece al relato: buena parte de quien se ha salvado, se ha salvado por una decisión que no tomó. El policy.xml que distribuye ImageMagick viene abierto a propósito —lo dice el propio proyecto: está pensado para entornos controlados—, pero después de la racha de fallos de Ghostscript de 2018 varias distribuciones, Debian y Ubuntu entre ellas, empezaron a empaquetar su propio policy.xml con los coders PS, EPS, PDF y XPS en rights="none", precisamente porque llamar a Ghostscript dejó de considerarse seguro. Quien tenga esa política puesta llevaba años con este camino cerrado sin saberlo. Es una defensa real, pero conviene llamarla por su nombre: no fue previsión tuya, fue herencia.
Quién tiene la llave de subir ficheros
La segunda condición es la cuenta. Hace falta una con la capacidad upload_files, que en una instalación por defecto tienen Autor, Editor y Administrador —el rol Colaborador no puede subir ficheros—. Cuando un aviso dice «requiere autenticación», mucha gente lo lee como si dijera «requiere ser tú». En un gestor de contenidos no significa eso. Significa requiere una cuenta de las que se regalan.
Piensa en la web corporativa real, no en la ideal. La agencia que la montó en 2019 sigue teniendo su usuario. La persona de marketing que subía las notas de prensa cambió de empresa en marzo. El becario del verano pasado nunca se dio de baja. Hay un plugin de membresía que asigna Autor a quien se registra, porque así venía configurado. Y hay un usuario llamado redaccion cuya contraseña conocen cuatro personas, tres de las cuales ya no trabajan ahí. A ninguna de esas cuentas la creó un atacante: las creamos nosotros, una a una, con un motivo razonable cada vez.
Diez minutos para saber si te toca
- ✓Qué versión corres de verdad.
wp core version, o el panel. Las ramas mantenidas recibieron su corrección: 7.0.4, 6.9.7, 6.8.8 y así hacia atrás. Si estás en una rama vieja y no la actualizas, aquí no hay medias tintas. - ✓Si tu servidor tiene las dos piezas. Sin consola: Salud del sitio → Información → Gestión de medios. Con consola:
php -m | grep -i imagickygs --version. - ✓Qué dice tu política de ImageMagick.
convert -list policyen ImageMagick 6,magick -list policyen la 7. Busca los coders PS, EPS, PDF y XPS conrights="none". Si están, tienes una segunda barrera que no depende de la versión de WordPress —pero no es una puerta cerrada: el mismo equipo que reportó este fallo publicó en marzo de 2026 varias formas de esquivar esa política, entre ellas que el módulo PDF acaba llamando al mismo delegado—. - ✓Quién puede subir ficheros.
wp user list --fields=user_login,roles,user_registeredy lee la lista entera, no por encima. Cada Autor, Editor y Administrador es una llave. Las que no reconozcas, primero bájalas a un rol sinupload_filesy bórralas cuando sepas qué cuelga de ellas: borrar un usuario en WordPress obliga a decidir si su contenido se borra o se reasigna, y ahí es donde se despublican artículos sin querer. - ✓Si el registro abierto reparte permisos. Mira el rol por defecto en Ajustes → Generales y lo que asigne cualquier plugin de membresía o de formularios. Un registro público que da Autor convierte «requiere autenticación» en «no requiere nada».
- ✓Qué hay en la carpeta de subidas. Ficheros recientes que no encajan con ningún contenido publicado,
.phpdonde solo debería haber medios, imágenes con fechas raras. No es un análisis forense, pero es la mirada que casi nadie da. Y si aparece algo, ten presente que actualizar no lo quita: el parche cierra la puerta, no limpia la casa.
Lo que no haríamos
Tres reflejos comunes que salen caros:
- ✕Desinstalar Imagick por si acaso. Es la reacción rápida y rompe cosas: WordPress cae a GD, cambian los recortes y la calidad de las miniaturas, y se pierde el procesado de formatos que a lo mejor usa tu tienda. Si vas a quitar algo, quita el coder concreto en la política, no la biblioteca entera.
- ✕Esperar a que el CVE tenga nota para decidir. A día de hoy CVE-2026-65640 sigue reservado en el NVD y las coberturas manejan un 8,8 sin autoridad primaria detrás. Tu urgencia no la fija esa cifra: la fijan tus dos condiciones. Con registro abierto y rol Autor por defecto, esto es peor que cualquier nota. Sin Ghostscript, es un cero.
- ✕Dejar las actualizaciones menores desactivadas «por estabilidad». Es la conversación que ya tuvimos con el fallo de julio: las webs con la actualización automática puesta se corrigieron solas de madrugada, y las «gestionadas» con las actualizaciones apagadas esperaron a que alguien se acordara el lunes.
A día de hoy no hay constancia pública de explotación de este fallo. Ayer mismo contamos hasta dónde vale esa frase: en el aviso de vCenter duró cinco días. Sirve para ordenar la cola, no para dormir tranquilo. Con Ghostscript instalado y cuentas de Autor repartidas, esto es de esta tarde.
Si solo te llevas una cosa
Actualiza a la versión corregida de tu rama, mira si tienes Ghostscript detrás y limpia la lista de gente que puede subir ficheros. Eso resuelve el caso concreto. Lo que no se resuelve actualizando es lo otro: tu web llama a bibliotecas que llaman a intérpretes que tú nunca elegiste —el mismo problema que contamos con la biblioteca que nadie eligió en Rails—, y cada una de ellas tiene su propia idea de qué es el fichero que le acabas de pasar. Por eso la pregunta que deja este aviso no es «¿estoy en la 7.0.4?», sino esta otra: ¿cuántas cuentas de tu web pueden subir un fichero, y cuándo fue la última vez que alguien leyó esa lista entera?
Fuentes (consultadas el 14 de agosto de 2026): fecha de la versión, descripción del fallo, crédito a pwn.ai, referencias CVE-2026-65640 y GHSA-8vr3-7mxf-gx8w y alcance del backport hasta la rama 4.7 — nota de la release WordPress 7.0.4; fecha de publicación de WordPress 4.7 y la función de miniaturas de PDF que estrenó — documentación de la versión 4.7 (la relación entre ambas cosas es lectura nuestra, no una declaración del proyecto); severidad, identificador, versiones corregidas por rama y descripción de la capacidad upload_files — aviso INCIBE-2026-552 del INCIBE-CERT (la cita va en su castellano original); contenido del arreglo en WP_Image_Editor_Imagick::load() — commit 7daaa50 de wordpress-develop; rutas de subida que no inspeccionan el contenido (XML-RPC y wp_upload_bits()) — análisis de Cyber Security News; carácter deliberadamente abierto de la política que distribuye el proyecto — política de seguridad de ImageMagick; formas de esquivar las restricciones de coders, publicadas en marzo de 2026 por el mismo equipo que reportó este fallo — investigación de pwn.ai. Ni WordPress ni INCIBE han publicado información sobre explotación en curso; cualquier afirmación sobre campañas concretas hoy sería especulación. Foto: «Alphabet letterpress», dominio público (CC0), vía Openverse (rawpixel).
¿Quién mira las aplicaciones que publicas a Internet?
En everyWAN trabajamos los datos y las aplicaciones con la misma exigencia que la infraestructura que hay debajo: quién entra, con qué permiso y qué bibliotecas corren detrás. Las miramos con los mismos ojos con los que miramos un cortafuegos, porque en ciberseguridad el inventario de lo que corre en un servidor incluye también lo que la aplicación llama sin decírtelo.
Hablar con everyWAN
Microsoft 365
ES 
CAT 
EN