WordPress parchea Comment2Shell, un fallo en los comentarios que puede llevar a la toma de control del servidor

WordPress publicó la versión 7.1.1 el 17 de septiembre de 2026, y no es la actualización de mantenimiento rutinario que sugiere su número de versión. La entrega incluye once correcciones de seguridad junto con sus correcciones de errores, y la más grave es un fallo de cross-site scripting almacenado que un visitante anónimo puede desencadenar mediante un comentario corriente. La vulnerabilidad, registrada como CVE-2026-93485, ha sido apodada Comment2Shell por adónde puede llevar: de un comentario en una cola de moderación a código ejecutándose en el servidor.

Lectura relacionada: Check Point parchea dos fallos de VPN de severidad 9.8 que permiten ejecución de código sin autenticación · SAP parchea una vulnerabilidad del kernel con CVSS 10.0 que no requiere credenciales.

El fallo está en wpautop(), la función de WordPress que convierte los saltos de línea del texto en marcado de párrafos. WordPress hace pasar el texto de los comentarios por ella antes de mostrarlo, y el error permite que un visitante sin cuenta introduzca script que supera el saneador de comentarios del sitio, wp_kses(), porque nada del contenido se parece al marcado que el saneador existe para eliminar. El script solo se vuelve peligroso después, cuando se renderiza el comentario y los filtros de visualización reordenan el texto.

La vulnerabilidad la reportó el investigador de seguridad Rafie Muhammad de Awesome Motive a través del programa de divulgación de vulnerabilidades de Patchstack el 15 de septiembre de 2026. WordPress publicó la corrección dos días después, y Patchstack la publicó en su base de datos el 18 de septiembre. La versión completa incluyó 17 correcciones de errores del núcleo y 21 correcciones del editor de bloques además del trabajo de seguridad.

Qué hace diferente a este caso

WordPress publica correcciones de seguridad con regularidad, y la mayoría requiere algún nivel de acceso para explotarse. Esta no. CVE-2026-93485 tiene una valoración de 7,1 en la escala CVSS 3.1, con un vector accesible por red, de baja complejidad, sin privilegios requeridos y con la condición de que alguien vea el contenido. Es el único de los once problemas de la versión al que puede llegar un atacante sin cuenta; la mayoría de los demás requieren un usuario con sesión iniciada y al menos acceso de nivel colaborador.

El análisis de Patchstack es directo sobre la salvaguarda de moderación. Las notas de la versión de WordPress describen el fallo como sujeto a aprobación de comentarios, lo que suena tranquilizador. El registro del CVE lo es menos: dice que el problema se reproduce en una instalación predeterminada porque la moderación manual de comentarios está desactivada por defecto, y porque el ajuste que retiene a un comentarista primerizo para su revisión puede eludirse. Eso significa que un contenido malicioso puede llegar a la cola de moderación en un sitio estándar, y que un atacante al que ya se le aprobó un comentario queda aprobado automáticamente a partir de entonces.

La razón por la que un fallo en los comentarios importa más de lo que parece al principio es quién lee los comentarios. Los visitantes los ven, pero también los moderadores y los administradores. Un script que se ejecuta en el navegador con sesión iniciada de un administrador puede actuar con los permisos de ese administrador, y a partir de ahí un atacante puede crear una nueva cuenta de administrador y usarla para ejecutar código en el servidor. El nombre Comment2Shell describe esa cadena y no el comentario en sí.

La brecha entre sanear y renderizar

El fallo ilustra por qué el filtrado de entrada es difícil. WordPress limpia un comentario cuando se guarda, usando wp_kses() para eliminar todo lo que parezca marcado ejecutable, y luego lo reformatea cuando carga la página, usando wpautop() para convertir los saltos de línea en párrafos. La vulnerabilidad vive en el espacio entre esos dos pasos. Un contenido que supera el saneador no es peligroso por sí solo; se vuelve peligroso cuando el filtro de visualización reordena el texto y el navegador interpreta el resultado como una etiqueta.

El análisis de Patchstack muestra que la corrección hace que la expresión de wpautop() reconozca las comillas, de modo que un corchete angular de cierre dentro de un valor entrecomillado ya no se lee como el final de una etiqueta. El cambio es pequeño, algo típico de las correcciones de cross-site scripting y también la razón por la que son fáciles de pasar por alto en una revisión. La lección que los equipos de seguridad extraen de errores como este es que el saneado y la renderización tienen que coincidir en qué significa la entrada, y que cualquier desajuste entre ambos es una posible vía de ejecución.

A quién afecta y cómo solucionarlo

Toda rama de WordPress desde la 4.7 en adelante es vulnerable por debajo de su propia compilación corregida. WordPress trasladó la corrección a todas las ramas compatibles, y las versiones corregidas para las líneas actuales son 7.1.1 para la rama 7.1, 7.0.5 para la 7.0 y 6.9.8 para la 6.9. Las ramas más antiguas, hasta la 4.7.36, recibieron sus propias compilaciones parcheadas. El proyecto recomienda actualizar de inmediato y señala que los sitios con actualizaciones automáticas en segundo plano activadas recogerán la corrección por su cuenta.

Para los administradores que no puedan actualizar enseguida, la mitigación práctica es cambiar las condiciones de las que depende el exploit. Activar la moderación manual de comentarios pone a una persona entre un comentario anónimo y la página, y cerrar los comentarios en entradas antiguas elimina por completo el punto de entrada. Ninguna de las dos sustituye al parche, y la nota de Patchstack de que la salvaguarda del comentarista ya aprobado puede eludirse significa que la moderación solo ayuda si los moderadores aprueban comentarios que reconocen como genuinos.

Las otras correcciones de la versión merecen tenerse por sí mismas. Incluyen un fallo de nivel colaborador que permitía a un usuario autenticado sobrescribir entradas que no eran suyas, un salto de ruta autenticado en el controlador de plantillas REST reportado por Anthropic, y varios problemas en la API HTML y en el manejo de temas. Ninguno es tan ampliamente alcanzable como el fallo de los comentarios, y todos se abordan con la misma actualización.

Un patrón conocido, con un filo más afilado

La versión continúa un año difícil para la seguridad del núcleo de WordPress. En julio, un fallo llamado wp2shell permitía a los atacantes ejecutar código sin ningún inicio de sesión, y las autoridades de EE. UU. lo incluyeron después como explotado en ataques reales. En agosto, los investigadores revelaron un fallo de scripting en otro componente. Comment2Shell es un error distinto con una corrección distinta, y su accesibilidad por parte de un visitante no autenticado lo sitúa en la misma categoría incómoda que aquellos problemas anteriores.

Lo que distingue a este es la vía de escalada y no el punto de entrada. El cross-site scripting en los comentarios es un problema antiguo, y el consejo estándar ha sido moderar los comentarios y mantener el software al día. La parte interesante de Comment2Shell es que el contenido sobrevive al saneador y luego convierte una acción administrativa rutinaria, abrir un comentario, en un paso hacia el compromiso del servidor. Es un recordatorio de que la seguridad de un sistema de gestión de contenidos depende de la acción menos privilegiada que invita, y no solo de las partes que se enfrentan directamente a internet.

El error es también un pequeño estudio de caso sobre la divulgación. Muhammad lo reportó a través de un programa coordinado, WordPress lo corrigió en dos días y Patchstack publicó los detalles un día después de la versión. Ese es el proceso funcionando. El mismo proceso significa que los detalles son ahora públicos y que la corrección es la única defensa, y por eso los investigadores describieron la actualización como urgente y no como aconsejable.

La lección práctica es que un formulario de comentarios rutinario es una superficie de seguridad. Los sitios que mantienen los comentarios abiertos en entradas antiguas, o que aprueban automáticamente a quienes ya han comentado, deberían tratar la cola de moderación como un punto de entrada y actualizar sin esperar a una ventana de mantenimiento. Los proveedores gestionados que operan muchas instalaciones también pueden comprobar si alguna está fijada a una rama no compatible, porque las correcciones retroportadas solo ayudan a los sitios que las aplican.

Qué observar

La pregunta inmediata es con qué rapidez se actualizará la larga cola de sitios de WordPress. WordPress mueve una gran parte de la web, y muchas instalaciones las mantienen personas que no siguen de cerca las versiones de seguridad. Los proveedores gestionados y las actualizaciones automáticas cerrarán buena parte de la brecha, y los sitios que se retrasan son los más propensos a ser sondeados en cuanto aparezca código de prueba de concepto.

Dos señales mostrarán si eso importa. La primera es si el fallo aparece en intentos de explotación o en la lista del gobierno de EE. UU. de vulnerabilidades explotadas activamente, algo que no había ocurrido cuando se publicó el parche. La segunda es si se publica un exploit funcional, ya que la corrección deja visible el cambio exacto y un contenido público acortaría el tiempo del que disponen los defensores. Los administradores de una rama compatible deberían dar la actualización por hecha cuando se aplica, no cuando se programa.

Portada: el panel de administración de WordPress, versión 7.0. Captura de pantalla de la WordPress Foundation, vía Wikimedia Commons, GPL, recortada a 16:9.