WordPress corrige Comment2Shell (CVE-2026-93485) con parche 7.1.1 para el núcleo 4.7–7.1

El 17 de septiembre WordPress publicó un parche que corrige una vulnerabilidad en el núcleo —registrada como CVE-2026-93485 y bautizada por la comunidad como "Comment2Shell"— que permitía a un visitante anónimo publicar un comentario que contenía un script oculto. Si un administrador autenticado abría después la página con ese comentario, el código podía aprovechar la sesión del administrador para ejecutar acciones con privilegios sobre el servidor, incluyendo la subida de un plugin malicioso que actúa como web shell. WordPress solucionó el problema en la versión 7.1.1 y alertó a los responsables de sitios a actualizar de inmediato. La nota de seguridad oficial de WordPress y la ficha CVE en el catálogo público recogen los detalles básicos.

Los hechos confirmados son los siguientes: la falla afecta a versiones del núcleo desde 4.7 hasta 7.1; WordPress lanzó correcciones específicas para cada rama (por ejemplo, 7.1 → 7.1.1, 7.0 → 7.0.5, 6.9 → 6.9.8 y otras ramas hasta 4.7.36); la vulnerabilidad fue reportada por el investigador Rafie Muhammad y descrita públicamente en una publicación técnica; Patchstack asignó y documentó la entrada y le dio una puntuación de 7.1/10 en la escala CVSS; y, según las declaraciones públicas hasta la fecha, no hay evidencia conocida de explotación en ataques masivos ni figura en listas gubernamentales de explotación activa. Patchstack mantiene una ficha con el análisis y la clasificación.

Técnicamente, la vulnerabilidad surge de una descoordinación entre dos pasos distintos en el tratamiento de comentarios: WordPress valida y filtra HTML "peligroso" cuando el comentario se guarda, y después aplica un reformatado (sanitizado/escapado) suplementario cuando el comentario se muestra en la página. El vector de ataque aprovechó un hueco entre esos procesos: al introducir deliberadamente un salto de línea dentro del atributo de una etiqueta HTML permitida en el comentario, la fase de renderizado fragmenta la etiqueta y mueve el texto del atacante a una posición que el navegador interpreta como un manejador de eventos (por ejemplo, un onload o similar). Ese manejador se ejecuta automáticamente al cargar la página, sin interacción del usuario. La ejecución del script ocurre en el contexto del navegador de quien carga la página y hereda el nivel de acceso de esa sesión.

Para escalar desde ejecución en el navegador a ejecución de código en el servidor hacen falta dos condiciones adicionales, ambas confirmadas por la investigación: primero, la víctima que abre la página debe ser un administrador autenticado; segundo, el script debe realizar acciones que empleen la sesión del administrador para subir un plugin malicioso (o activar rutas equivalentes de importación de código). La técnica de subir un plugin que contenga un web shell es un camino bien conocido para convertir una sesión de administrador en control persistente del servidor.

Importante: la vulnerabilidad no afecta a todos los sitios por igual. Funciona únicamente en sitios cuyo tema (o esquema de comentarios) formatea los comentarios de la forma vulnerable: ocurre en temas block y en algunos temas clásicos que replican el mismo reformatado. Además, aunque WordPress describió la falla como "explotable sujeto a la aprobación de comentarios", la moderación por defecto y las reglas de primera vez para comentar no constituyen un control infalible: la configuración puede dejar comentarios sin moderación, y en muchos escenarios la barrera de moderación puede ser sorteada o no estar activada. Patchstack resumió esto con la observación de que "la moderación no es un control de seguridad".

Sobre el riesgo real: confirmado está que la vulnerabilidad permite, en condiciones específicas, una escalada a ejecución en servidor si un administrador visita la página afectada. Lo que sigue siendo incierto o una estimación razonable es si actores maliciosos ya han aprovechado Comment2Shell en campañas reales —hasta ahora no hay evidencia pública de explotación— y qué número de instalaciones en producción cumplen todas las condiciones necesarias (tema vulnerable, comentarios públicos alcanzables, administradores que visiten la página). Aun en ausencia de prueba de explotación masiva, la combinación de facilidad de publicación de comentarios y de administradores que visitan páginas públicas hace que el defecto sea operativo y digno de atención inmediata.

Qué debe hacer ahora un responsable de sitio WordPress: lo primero y obligatorio es actualizar el núcleo a la versión corregida para su rama. Las versiones a instalar son, como mínimo: 7.1 → 7.1.1; 7.0 → 7.0.5; 6.9 → 6.9.8; y, si usa ramas anteriores hasta 4.7, instalar la versión parcheada disponible para esa rama (las correcciones fueron publicadas para las ramas con soporte). La actualización cierra la vulnerabilidad, pero no restaura cambios que un atacante ya hubiera realizado.

Si no puede aplicar la actualización de forma inmediata, mitigue el vector bloqueando la publicación de nuevos comentarios públicos: cierre los comentarios en entradas antiguas, o desactive los comentarios de forma global hasta actualizar. Un firewall de aplicaciones web (WAF) o plugins de seguridad (por ejemplo, reglas comerciales en Cloudflare, Sucuri o reglas de mod_security) pueden interceptar y bloquear la carga del comentario malicioso, aunque la efectividad depende de las firmas y reglas disponibles. No confíe únicamente en la moderación de comentarios como defensa.

Si sospecha que su sitio pudo haber sido comprometido antes del parche, realice las siguientes comprobaciones concretas: busque plugins o archivos nuevos o modificados en wp-content/plugins y wp-content/uploads; revise listas de plugins activos y compare con inventarios anteriores; use herramientas como 'wp core verify-checksums' (WP-CLI) para detectar archivos de núcleo alterados; escanee el sitio con motores de reputación y malware (Wordfence, Sucuri, VirusTotal para archivos sospechosos); compruebe cron jobs, cuentas de usuario y entradas inusuales en los logs de acceso/errores del servidor; y cambie las contraseñas administrativas e invalide sesiones activas (cerrar todas las sesiones). Todo trabajo de limpieza debe realizarse sobre una copia o en mantenimiento, y es recomendable restaurar desde una copia de seguridad limpia si se detecta compromiso.

Como medidas preventivas adicionales que conviene aplicar después de la corrección: limite la capacidad de instalar plugins/themes a unas pocas cuentas de confianza, habilite autenticación multifactor para cuentas administrativas, restrinja el acceso a /wp-admin por IP o mediante autenticación HTTP adicional si es posible, y mantenga actualizadas las extensiones y temas. Evalúe la adopción de un WAF gestionado y de alertas de integridad de archivos para detectar manipulaciones tempranas.

Fuentes y documentación técnica pública sobre el parche y la clasificación están disponibles en la nota de WordPress y en la ficha de Patchstack; la entrada CVE pública ofrece la designación oficial de la vulnerabilidad. Revise esos anuncios y programe la actualización tan pronto como sea posible: los parches están disponibles y aplicar la corrección es la acción que elimina la ventana de exposición. Ficha CVE (Mitre) y Patchstack - CVE-2026-93485 contienen más detalles técnicos y referencias.