Ayer WordPress sacó la 7.0.4 y, como casi siempre, el titular suena a alivio: parche de seguridad, actualiza ya, fin del problema. Lo que no te cuentan en el changelog es que la vulnerabilidad (CVE-2026-65640) no es un fallo raro de un plugin olvidado, sino un agujero en el propio core que lleva años acechando detrás de Imagick y Ghostscript. Un autor con cuenta de colaborador sube un PNG que no es un PNG, ImageMagick se lo traga, y de repente alguien ejecuta código en tu servidor. Yo lo he visto en clientes que tenían «solo tres autores de confianza» hasta que descubrieron que el cliente había dado acceso a una agencia de contenidos, a un redactor freelance y al becario de verano.
La noticia la han cubierto Cybersecurity News y Patchstack, y ambos dicen lo mismo con distinto tono: actualiza, que el parche inspecciona el contenido real del archivo antes de pasárselo a Imagick. Bien. Pero me parece que el sector está celebrando el parche como si cerrara el debate, cuando en realidad solo pone un tirita sobre una herida estructural.
El PNG que no era PNG
El vector es elegante y viejo como Ghostscript: subes un archivo con extensión de imagen, pero por dentro lleva firmas PostScript, EPS o un PDF disfrazado. WordPress confiaba en la extensión y en que ImageMagick sabría lo que hacía. ImageMagick, a su vez, delegaba en Ghostscript para ciertos formatos. Ghostscript tiene un historial larguísimo de ser engañado para ejecutar comandos que no debería. El commit 7daaa50 reescribe la función load() de WP_Image_Editor_Imagick para oler el primer chunk del archivo y rechazar lo sospechoso antes de construir el objeto Imagick.
En paper suena impecable. En la práctica, me pregunto cuántos hosting compartidos siguen teniendo Imagick activo con Ghostscript accesible porque «así van más rápidas las miniaturas». He revisado paneles de pymes este año y la respuesta típica del soporte es «Imagick viene activado por defecto, no lo toques». Genial para el rendimiento, menos genial cuando un autor comprometido — o un autor con la contraseña filtrada — puede convertir la biblioteca de medios en puerta de entrada.
«Requiere rol Autor» no es tranquilizador
WordPress insiste en que hace falta al menos rol Autor. Eso excluye ataques anónimos drive-by, sí. Pero piensa en tu instalación real: cuántos sitios de membresía, revistas digitales, marketplaces de contenido o webs de cliente con «acceso para que suban ellos las fotos» tienen cuentas Autor repartidas como caramelos en una verbena? En mi experiencia, muchos. El becario de marketing, la agencia externa, el community manager que pidió permisos «solo para esta campaña» y nadie revocó.
Lo que me choca es que WordPress lleva décadas empujando roles granulares y luego aparecen vulnerabilidades donde el límite de seguridad es «confía en que nadie con Autor va a hacer nada raro». No es una amenaza teórica: Patchstack lo dice claro, en sitios con registro abierto o gestión laxa de cuentas, un PNG trampa es un vector realista. Y sin embargo el mensaje oficial sigue siendo «actualiza y sigue dando Autor a quien lo pida».
El parche no arregla tu gobernanza de cuentas
Actualizar a 7.0.4 es obligatorio. Lo haría hoy mismo en cualquier sitio que gestiono. Pero actualizar no es estrategia de seguridad, es higiene mínima. Lo que no veo en la conversación pública — ni en los comunicados de hosting, ni en los emails automáticos de «hemos parcheado por ti» — es una recomendación seria de auditar quién tiene Autor, Colaborador o superior, cuándo fue la última vez que alguien revisó esas cuentas, y si realmente necesitas Imagick activo en un servidor donde no procesas PDFs ni EPS en la biblioteca de medios.
Algunos hosts managed presumen de «WordPress seguro» y aplican el parche en caliente. Perfecto. Pero rara vez te dicen: «oye, tienes 14 usuarios con capacidad de subir medios, cuatro llevan más de un año sin entrar y uno usa una contraseña que apareció en una filtración». Eso no entra en el SLA. Entra en tu checklist, si es que tienes uno.
Imagick sigue siendo la bomba de relojería que nadie quiere desactivar
Desactivar Imagick y quedarte con GD no es gratis: pierdes calidad en ciertos redimensionados y algunos plugins protestan. Por eso casi nadie lo hace. Pero mantener la cadena Imagick + Ghostscript en un hosting compartido de 5 euros al mes, con cientos de cuentas vecinas, me parece una apuesta que el precio no refleja. Los benchmarks de rendimiento premian Imagick; los informes de incidentes premian la superficie de ataque mínima. El mercado elige velocidad en la landing de ventas y seguridad en el comunicado posterior al hackeo.
Tampoco ayuda que el backport llegue «hasta la rama 4.7» según anuncian, pero solo la última versión recibe soporte completo. Conozco sitios en 6.x que llevan meses sin entrar al escritorio porque «funciona y no tocamos nada». Esos no van a leer GHSA-8vr3-7mxf-gx8w un martes cualquiera. Van a enterarse cuando el SEO se desplome porque alguien inyectó enlaces farmacéuticos en el footer.
Lo que haría yo hoy, más allá del botón Actualizar
Primero, versión: 7.0.4 o superior, comprobado en producción y staging. Segundo, inventario de cuentas con capacidad de subir archivos: bajar a Colaborador o Suscriptor a quien no lo necesite, eliminar inactivos, MFA donde se pueda (sí, en WordPress también). Tercero, preguntar al hosting si Imagick usa Ghostscript y si pueden desactivarlo sin romper tu flujo. Cuarto, si tienes Patchstack, Wordfence o similar, confirmar que la regla de mitigación está activa — Patchstack desplegó regla a sitios conectados antes incluso del parche oficial, y eso sí es valor añadido frente al «ya hemos actualizado el core» genérico.
Quinto, algo que casi nadie hace: revisar logs de subidas recientes en la biblioteca de medios. Un PNG trampa no grita; a veces deja rastro en errores de procesamiento de imagen antes de que alguien lo explote bien. Si ves fallos raros al generar miniaturas, no los ignores.
WordPress ha hecho su parte con el parche. El ecosistema — hosting, agencias, dueños de tienda — sigue actuando como si la seguridad fuera un evento puntual y no un proceso. Y eso, sinceramente, me preocupa más que un CVE concreto, porque el siguiente también llegará por una cadena de confianza que nadie audita.
Si mañana tu hosting te ofreciera desactivar Imagick a cambio de 200 ms más en la generación de miniaturas pero eliminar por completo este vector en tu servidor, aceptarías el trato o seguirías priorizando el PageSpeed de la semana?