WordPress 7.0.4: parcha la vulnerabilidad RCE CVE-2026-65640

En pocas palabras: WordPress 7.0.4, lanzado el 13 de agosto de 2026, parchea CVE-2026-65640 (CVSS 8.8), una vulnerabilidad RCE que permite a cualquier usuario con rol Author ejecutar código arbitrario en el servidor vía ImageMagick y Ghostscript. El parche se retroportó hasta WordPress 4.7. Actualizá de inmediato.

WordPress publicó el 13 de agosto de 2026 la versión 7.0.4, que parchea CVE-2026-65640, una vulnerabilidad RCE con CVSS 8.8. La falla permite a usuarios con permisos de Author o superiores cargar un archivo PNG con PostScript malicioso embebido y ejecutar código arbitrario en el servidor a través de ImageMagick y Ghostscript.

CVE-2026-65640 es una vulnerabilidad de ejecución remota de código (RCE) en WordPress que afecta a instalaciones que usan ImageMagick (a través de la extensión Imagick) junto con Ghostscript, con puntuación CVSS de 8.8. Un atacante con permisos de Author o superiores puede cargar un archivo PNG que contiene código PostScript: WordPress lo acepta por su extensión, Imagick detecta el PostScript por su contenido y Ghostscript lo ejecuta en el servidor. El parche oficial está en WordPress 7.0.4, retroportado hasta la versión 4.7.

¿Qué es CVE-2026-65640 y cómo funciona el ataque?

CVE-2026-65640 es la vulnerabilidad RCE de WordPress parchada el 13 de agosto de 2026 con CVSS 8.8. El vector de ataque explota una diferencia de criterios entre dos componentes del servidor: WordPress mira la extensión del archivo para decidir si lo acepta; ImageMagick mira el contenido para decidir qué hacer con él. Esa divergencia es la brecha.

Ponele que sos Author en un blog colaborativo. Armás un archivo con extensión .png pero adentro lleva código PostScript. Lo subís como imagen de portada de tu nota, WordPress lee la extensión y lo aprueba sin preguntar, lo pasa a la clase WP_Image_Editor_Imagick para generar las miniaturas, Imagick abre el archivo, escanea el contenido byte a byte, detecta que hay PostScript embebido, llama a Ghostscript para renderizarlo y Ghostscript ejecuta ese código en el servidor como si fuera cualquier tarea de procesamiento normal (spoiler: no lo es). En soluciones de seguridad profesionales para WordPress profundizamos sobre esto.

Según el análisis de Patchstack, WordPress tiene una función que realiza verificaciones de contenido, pero ciertos flujos de carga la esquivan. Ese hueco específico es lo que convierte el bug técnico en una vulnerabilidad explotable.

¿A quiénes afecta realmente esta vulnerabilidad?

La vulnerabilidad afecta instalaciones de WordPress entre las versiones 4.7 y 7.0.3, con dos condiciones obligatorias: la extensión Imagick activa en PHP y Ghostscript instalado en el servidor. Sin esos dos componentes a la vez, el ataque no llega a ningún lado (que no es un filtro menor).

El otro requisito es una cuenta con permisos de Author o superior, específicamente la capacidad upload_files. Eso descarta ataques anónimos, pero no hace al bug inofensivo: en sitios con múltiples autores, membresías abiertas o plataformas colaborativas donde personas externas tienen cuentas con permisos de carga, el riesgo es concreto. La pregunta es cuántos sitios con esa configuración auditan con frecuencia real sus usuarios Author.

Tipos de sitios con mayor exposición:

• Redes multisitio WordPress: múltiples autores con upload_files en varios subsitios
• Sitios de membresía: usuarios externos con roles de contribuidor o autor habilitados por defecto
• Plataformas colaborativas: alta rotación de cuentas, permisos que se asignan y raramente se auditan

¿Cuáles son los componentes técnicos detrás de la vulnerabilidad?

PostScript es un lenguaje de programación diseñado para describir páginas, pero con capacidad real de ejecutar operaciones en el sistema operativo. Ghostscript es el intérprete que lo ejecuta. Cuando ImageMagick detecta PostScript en un archivo, lo delega automáticamente a Ghostscript para procesarlo. Esa delegación es legítima en flujos normales; el problema es que WordPress no verificaba que el contenido del archivo coincidiera con lo que prometía la extensión.

La «validación» por extensión resultó ser el eslabón más débil de toda la cadena. WordPress pasaba el archivo a ImageMagick basándose en la extensión, y ahí terminaba su responsabilidad. Lo que ImageMagick encontrara adentro era problema de ImageMagick. Y ImageMagick, fiel a su diseño, delegó a Ghostscript sin más preguntas. Para más detalles técnicos, mirá autenticación de dos factores en WordPress.

¿Cuál fue el error de diseño en WordPress que permitió esto?

El problema de fondo es clásico: dos componentes del stack evalúan el mismo archivo con criterios distintos y ninguno sabe lo que hace el otro. WordPress decidió que la extensión era suficiente garantía del tipo de archivo; ImageMagick decidió que el contenido era lo que importaba. Nadie reconcilió esos dos criterios hasta que alguien los explotó.

¿Y qué pasó cuando alguien unió esos puntos y lo reportó? Exacto: WordPress lanzó el parche. La clase WP_Image_Editor_Imagick manejaba el procesamiento de imágenes sin validar que el contenido coincidiera con la extensión declarada. No es un descuido inexplicable, pero tampoco es menor viniendo de un CMS que procesa el 40% de la web (si es que eso cuenta como atenuante).

¿Cómo actualizar WordPress para parchar CVE-2026-65640?

WordPress 7.0.4 está disponible desde el 13 de agosto de 2026. Según el anuncio oficial de WordPress, el parche se retroportó a todas las ramas activas desde la 4.7 en adelante. Si tu sitio corre una versión anterior, debería haber una actualización disponible en tu línea.

• Desde el panel de administración: Tablero > Actualizaciones > aplicar la versión disponible de tu rama
• Vía WP-CLI: wp core update
• En multisitio: actualizar desde el panel del superadministrador aplica a toda la red
• Verificación post-update: Tablero > En un vistazo > confirmar la versión activa

Si tu WordPress está en hosting administrado, por ejemplo en donweb.com, preguntá si la actualización de seguridad ya se aplicó automáticamente. Si administrás el servidor vos mismo, la actualización es manual salvo que tengas habilitadas las actualizaciones automáticas del core.

¿Qué protecciones alternativas existen si no puedo actualizar inmediatamente?

La mitigación más directa es desactivar Imagick y forzar que WordPress use GD Library en su lugar. Sin Imagick en el flujo de procesamiento, la cadena de ataque no existe. Después viene la actualización; esto es provisorio.

• Forzar GD Library: usando un plugin de configuración o snippet en functions.php que defina WP_Image_Editor_GD como editor preferido
• Revisar permisos de Author: quitar upload_files a usuarios que no lo necesitan realmente
• Auditoría de cuentas: listar todos los usuarios con roles Author o superior y confirmar que siguen siendo legítimos
• WAF con inspección de contenido: puede detectar PostScript en archivos subidos como imágenes; no reemplaza el parche, es una capa extra

¿Cómo detectar si mi sitio fue comprometido por esta vulnerabilidad?

Si tu servidor tenía Imagick y Ghostscript antes del parche y hay usuarios con permisos Author activos, vale la pena revisar. Las señales de una explotación exitosa no son distintas a las de cualquier webshell, pero el vector específico deja rastros en zonas concretas. Te puede servir nuestra cobertura de implementar 2FA de forma correcta.

• Revisar wp-content/uploads: buscá archivos .php que no debería haber ahí; es el rastro más típico de un webshell depositado vía este tipo de ataque
• Logs del servidor: peticiones POST a wp-admin/async-upload.php seguidas de GET sospechosos a rutas dentro de uploads
• Integridad del core: wp core verify-checksums vía WP-CLI detecta modificaciones en archivos de WordPress
• Escaneo con Wordfence: un escaneo completo identifica archivos inyectados o modificaciones en el core

Si encontrás un PHP en el directorio de uploads que vos no pusiste: limpiá, restaurá desde un backup previo limpio y rotá todas las credenciales de base de datos y acceso al servidor.

Errores comunes al responder a esta vulnerabilidad

Error 1: «Tengo Wordfence activado, ya estoy protegido.» Los firewalls de plugins operan a nivel de request HTTP, no siempre interceptan el procesamiento interno de imágenes que ocurre después de que la carga fue aceptada. El WAF es una capa útil, pero no reemplaza el parche del core. Actualizá igual.

Error 2: «No tengo Imagick instalado» (sin verificarlo). Imagick es la librería de procesamiento predeterminada en la mayoría de los servidores PHP modernos con GD como fallback, no al revés. Antes de asumir que no está, verificalo con phpinfo() o preguntando a tu proveedor de hosting. Muchos sitios tienen Imagick activo sin saberlo.

Error 3: Revocar permisos de Author a todos sin auditar primero. Deshabilitar upload_files masivamente cierra el vector, pero puede romper flujos editoriales legítimos que después tenés que revertir uno a uno. La solución es auditar quién realmente necesita ese permiso, no aplicar una revocación global y apagar el incendio con agua. Ya lo cubrimos antes en proteger tu WordPress de ataques.

Preguntas Frecuentes

¿Qué es CVE-2026-65640 y por qué afecta mi WordPress?

CVE-2026-65640 es una vulnerabilidad RCE en WordPress con CVSS 8.8, parchada en la versión 7.0.4 del 13 de agosto de 2026. Afecta a sitios que usan la extensión Imagick junto con Ghostscript. Un atacante con permisos de Author puede cargar un PNG con PostScript embebido: WordPress aprueba el archivo por su extensión, Imagick detecta el PostScript por el contenido y Ghostscript lo ejecuta. Instalaciones sin Imagick o sin Ghostscript no son vulnerables.

¿Necesito actualizar a WordPress 7.0.4 si no uso Imagick?

Si tu servidor no tiene Imagick instalado, CVE-2026-65640 no te afecta en particular. Aun así, actualizar a 7.0.4 o a la versión retroportada de tu rama sigue siendo lo correcto: el parche acumula otras correcciones y dejar el core sin actualizar es una deuda que crece. Verificá primero si Imagick está activo con phpinfo(); muchos sitios lo tienen sin saberlo.

¿Cuáles son los riesgos reales de la vulnerabilidad de PostScript en WordPress?

Una explotación exitosa le da al atacante ejecución de código en el servidor con los permisos del proceso web, lo que en la práctica significa acceso completo: instalación de webshells, lectura de credenciales de base de datos, defacement o uso del servidor como punto de pivote. El CVSS 8.8 refleja ese alcance. El límite real es que se necesita una cuenta Author activa, no es un ataque anónimo desde el exterior.

¿Cómo proteger mi sitio WordPress de la vulnerabilidad RCE mientras actualizo?

La mitigación más efectiva antes de actualizar es forzar que WordPress use GD Library en vez de Imagick para el procesamiento de imágenes. Sin Imagick en el flujo, Ghostscript nunca entra. Como segundo paso, revisá que ningún usuario externo tenga permisos de Author sin necesitarlo. Ambas acciones reducen la superficie de ataque mientras preparás la actualización del core.

¿Cómo detectar si alguien ya explotó esta vulnerabilidad en mi sitio?

El rastro más claro de una explotación exitosa es encontrar archivos .php en el directorio wp-content/uploads que vos no creaste: eso indica un webshell depositado. Revisá también los logs del servidor buscando peticiones POST al endpoint de carga seguidas de GET sospechosos. wp core verify-checksums vía WP-CLI detecta modificaciones en archivos del core que no deberían haber cambiado.

Conclusión

CVE-2026-65640 es uno de esos bugs que generan cierta vergüenza ajena: dos componentes evalúan el mismo archivo con criterios distintos y nadie lo reconcilió hasta que alguien lo explotó. El CVSS 8.8 es alto pero no catastrófico, porque requiere una cuenta con permisos reales. Aun así, en sitios con autores múltiples o membresías abiertas, ese requisito no es difícil de cumplir.

WordPress 7.0.4 cierra la brecha, y el parche está retroportado hasta la 4.7, así que prácticamente cualquier instalación activa tiene una actualización disponible hoy mismo. Si por alguna razón no podés actualizar ahora, desactivar Imagick es la mitigación más limpia. Y si nunca habías pensado en auditar quién tiene permisos de Author en tu sitio, según SecurityWeek este tipo de vulnerabilidad orientada a usuarios autenticados está siendo cada vez más explotada. Este es el momento.

Fuentes

• WordPress.org — Anuncio oficial de WordPress 7.0.4
• Patchstack — Análisis técnico de la vulnerabilidad Imagick RCE
• SecurityWeek — Cobertura de CVE-2026-65640 en WordPress 7.0.4
• CyberSecurityNews — Detalles de la vulnerabilidad Imagick RCE
• El Hacker — Vulnerabilidad RCE en WordPress con Imagick (en español)