WordPress 7.1.1: los 11 fallos de seguridad corregidos y por qué actualizar ya

Por Daniele Forciniti

Índice

WordPress 7.1.1 es la actualización de seguridad y mantenimiento publicada el 17 de septiembre de 2026: corrige 11 vulnerabilidades, 17 errores del core y 19 del editor de bloques. La más seria permite que un visitante cualquiera, sin cuenta y sin contraseña, deje un comentario con código dentro, código que acaba en la página y se ejecuta en el navegador de quien la abre. Hay que instalarla ya, y si tienes las actualizaciones automáticas activas es muy probable que ya la tengas.

Los otros diez fallos necesitan una cuenta en el sitio, pero tres se explotan con los permisos más bajos que existen, los de colaborador, y uno funciona con cualquier usuario registrado. En este artículo los tienes los once explicados uno a uno, con quién los reportó, cuánto pesan de verdad, cómo saber si alguien ya lo ha intentado en tu web y cómo actualizar sin romper nada.

Por qué esta vez conviene ir deprisa

Las actualizaciones menores de WordPress salen a menudo y casi siempre afectan a problemas que un atacante solo puede aprovechar si ya tiene un pie dentro. Esta vez no. El fallo principal, registrado como CVE-2026-93485 con puntuación CVSS 7.1, tiene la barrera de entrada más baja de todo el paquete: no hace falta ninguna cuenta, basta con el formulario de comentarios abierto al público.

Hay una condición que rebaja la alarma: el comentario tiene que publicarse, así que normalmente pasa por moderación. Pero cuidado con cómo está configurada tu web, porque WordPress trae de serie la opción que aprueba automáticamente a quien ya tuvo un comentario aprobado antes. Si esa opción está activa, y en la mayoría de los sitios lo está, al atacante le basta con dejar primero un comentario inofensivo, esperar tu visto bueno y a partir de ahí publicar solo.

Traducido: si tienes un blog con comentarios abiertos, esta corrección importa más que las otras diez juntas. Si los tienes cerrados en todas partes puedes respirar, pero no te saltes la actualización igualmente, porque el resto de fallos toca los permisos de los usuarios y cualquier web con varios redactores está expuesta.

Qué falló dentro de wpautop, explicado fácil

Esta parte técnica merece contarse, porque explica algo que mucha gente no espera: el contenido puede estar limpio cuando lo guardas y volverse peligroso cuando lo muestras.

wpautop() es la función que convierte los saltos de línea en párrafos. Es la que hace que escribas dos líneas separadas por un intro y en pantalla salgan dos <p>. Se ejecuta prácticamente en todo el contenido que WordPress imprime, artículos y comentarios incluidos. Para hacer su trabajo sustituye los saltos de línea por comentarios HTML temporales y luego lo recompone todo.

El problema estaba en una expresión regular que buscaba las etiquetas con el trozo ([^>]*), es decir «coge todo hasta el primer mayor que». Esa forma de buscar no tiene en cuenta los atributos entrecomillados: si dentro de un atributo aparece un carácter >, y los comentarios que inserta la función generan varios, la etiqueta se parte por donde no debe y lo que era texto inofensivo pasa a ser marcado real.

Por eso el filtro de limpieza de comentarios, wp_kses(), no lo frenaba: al guardar, esa cadena no parece peligrosa, no lleva ninguna etiqueta prohibida, solo texto dentro de un atributo. Se convierte en script después, durante el formateo de salida. En mis años arreglando webs comprometidas he visto este patrón varias veces, la comprobación en un sitio y el daño naciendo en otro, y es el tipo de error más incómodo de encontrar a mano.

Los once fallos corregidos, uno a uno

El aviso oficial los enumera en desorden y sin explicarlos. Aquí van ordenados por lo fácil que es explotarlos, con la traducción de qué significa cada uno para quien tiene una web.

Qué permite hacer	Hay que ser	Quién lo reportó
Inyectar scripts mediante los comentarios, aprovechando el formateo de párrafos	Ninguna cuenta, solo el comentario aprobado	Rafie Muhammad (Awesome Motive)
Mover comentarios, notas incluidas, bajo otro contenido	Cualquier usuario registrado	viridis
Leer el título de una entrada privada a través de los datos de un adjunto	Usuario registrado con acceso a medios	HDWSec
Sobrescribir entradas de otros	Colaborador o superior	Anthropic
Salirse de las carpetas previstas en el controlador de plantillas de la API REST	Usuario autenticado	Anthropic
Descubrir los slugs de borradores y entradas pendientes de revisión	Colaborador o superior	hermanhms
Publicar changesets saltándose la comprobación del CSS personalizado, vía XML-RPC	Autor o superior	Ben Bidner (equipo de seguridad de WordPress)
Inyectar scripts en las imágenes de cabecera de algunos temas	Quien gestiona la apariencia del tema	Jeremy Felt (equipo de seguridad de WordPress)
Instalar y previsualizar un tema de WordPress.org con una URL manipulada	Administrador que abre el enlace	Paulos Yibelo y pwn.ai
Activar en toda la red un plugin reservado a la red	Administrador de un sitio en multisitio	Jesse McNeil
Hacer que el texto salga de un comentario HTML en la API HTML	Depende de cómo el tema o el plugin usen la API	Jeremy Felt (equipo de seguridad de WordPress)

Tres merecen dos líneas más. La sobrescritura de entradas es la que más daño hace en una web con varios autores: el rol colaborador es el que se da a quien escribe pero no publica, y en teoría no puede tocar el trabajo de los demás. El path traversal en la API REST afecta al controlador de plantillas, la parte que sirve los archivos del tema de bloques: salirse de la carpeta prevista significa leer archivos que no deberías ver. Lo de mover comentarios parece una tontería, pero las notas internas de WordPress son comentarios a todos los efectos, y moverlas significa hacerlas aparecer donde no tocan.

Gráfico: qué nivel de acceso hace falta para explotar los 11 fallos corregidos en la 7.1.1 — Solo uno de los once fallos no necesita ninguna cuenta, y es el de los comentarios.

Dos de los once avisos vienen de Anthropic

Esta es la parte que nadie cuenta y que para mí pesa más que el parche concreto. Dos de los once fallos, la sobrescritura de entradas y el path traversal de la API REST, están acreditados a Anthropic, la empresa que desarrolla Claude. Un tercero, el del tema instalado mediante una URL manipulada, llega de pwn.ai junto al investigador Paulos Yibelo.

No es un caso aislado. Como ha reconstruido The Repository, desde julio todas las entregas de seguridad de WordPress citan a empresas de inteligencia artificial, ya sea como reportantes o por el uso de sus modelos en el descubrimiento. La versión de emergencia 7.0.2 cerró un fallo crítico explotable sin autenticación, encontrado por un investigador que se apoyó en un modelo de OpenAI. La 7.0.3 corrigió doce citando a Anthropic, pwn.ai y Aikido Security. La 7.0.4, una semana después, otra ejecución de código.

Los números lo dicen todo: los avisos al programa HackerOne de WordPress han pasado de una media de 20-30 al mes, estable durante diez años, a 773 solo en agosto. El 1 de septiembre el proyecto formalizó una iniciativa dedicada a la seguridad del core y subió el listón para aceptar avisos de gravedad baja, sencillamente porque el equipo ya no daba abasto.

Para quien tiene una web el significado es concreto y hay que decirlo claro: los fallos no están aumentando, está aumentando la velocidad a la que se encuentran. Ya estaban ahí antes, en algunos casos desde hace años. La consecuencia es que las actualizaciones de seguridad saldrán más a menudo de lo que estamos acostumbrados, y quien actualiza de vez en cuando quedará expuesto más tiempo que antes. Quien encuentra los fallos hoy usa herramientas automáticas: es razonable esperar que quien los explota haga lo mismo.

Cómo actualizar a WordPress 7.1.1 sin romper nada

El camino normal es el del escritorio: Actualizaciones y luego Actualizar ahora. Antes de pulsar, eso sí, hay cuatro cosas que hago siempre y que en diez años me han evitado unas cuantas tardes torcidas.

Una copia de seguridad que sepas restaurar. Base de datos y archivos, y sobre todo la certeza de saber volver atrás. Una copia que nunca has probado no es una copia, es una esperanza.
Actualiza antes plugins y tema, después el core. Casi todos los problemas posteriores a una actualización nacen de un plugin rezagado, no del core.
Si tienes tienda o código a medida, pasa por staging. En una tienda la prueba no es la portada: son carrito, envíos, impuestos, cupones, pago y correos de confirmación.
Elige una hora tranquila. Ni el viernes a las siete, ni en mitad de una campaña activa.

Si trabajas desde terminal, con WP-CLI actualizar y comprobar son tres comandos: wp core update para instalar, wp core verify-checksums para verificar que los archivos del core son idénticos a los oficiales (sirve también para descubrir archivos modificados por otro) y wp plugin list --update=available para ver qué queda pendiente.

Sobre las actualizaciones automáticas: WordPress instala solo las menores como esta, salvo que alguien las haya desactivado. Vale la pena comprobarlo de verdad en lugar de darlo por hecho, porque pasa a menudo que un hosting o un plugin de mantenimiento las apagó en su día y luego nadie se acuerda. En la pantalla de actualizaciones pone claramente si el sitio recibe o no las actualizaciones automáticas.

Daniele Forciniti · DF Studio Design

Las actualizaciones de seguridad no esperan a que tengas tiempo

Con los avisos pasando de treinta al mes a casi ochocientos, los parches saldrán cada vez más seguido. La cuestión no es correr cada vez: es tener una copia de seguridad que funcione, un staging donde probar y alguien que mire la web cuando sale un parche importante.

Me llamo Daniele Forciniti: llevo diez años haciendo webs y posicionamiento, y dos trabajando también en GEO. Si tu web está en producción y no te apetece pensar en esto cada mes, me encargo yo.

Asistencia WordPress Diseño web WordPress

Cómo saber si alguien ya lo ha intentado

Esta es la pregunta que me hacen siempre y a la que ninguno de los artículos que he leído por ahí responde. Ninguna de estas comprobaciones da una certeza absoluta, pero juntas dicen bastante y se hacen en un cuarto de hora.

La cola de comentarios. Revisa aprobados, pendientes y spam buscando <script, onerror=, onload= y javascript:. Desde terminal: wp comment list --search="onerror" --field=comment_ID. Fíjate también en comentarios genéricos y sosos de usuarios que no habías visto nunca, que sirven para colar la primera aprobación.
Los usuarios. wp user list --role=contributor y --role=author: si aparecen cuentas que no has creado tú, el problema es más gordo que este parche.
Los temas instalados. wp theme list: un tema que no recuerdas haber instalado es exactamente el resultado del fallo de la URL manipulada.
Los changesets del personalizador. wp post list --post_type=customize_changeset --post_status=any: guardan los cambios del personalizador, y una cantidad rara o entradas recientes que no corresponden a cambios tuyos hay que mirarlas.
La integridad del core. wp core verify-checksums te dice si algún archivo de WordPress es distinto del oficial.
Los registros del hosting. Busca llamadas repetidas a xmlrpc.php: el fallo del CSS personalizado pasa por ahí, y si no usas XML-RPC para nada merece la pena cerrarlo del todo.

Si encuentras algo que no cuadra, actualiza primero, luego cambia las contraseñas de los administradores e invalida las sesiones abiertas. Un consejo que doy siempre: no borres las huellas enseguida, porque sirven para entender por dónde entró.

¿Y si la web está parada en una versión antigua?

Aquí WordPress hace algo que pocos proyectos hacen: las correcciones se han llevado hacia atrás a todas las ramas todavía elegibles, hasta la 4.7 de 2016. Significa que incluso una web parada en una versión vieja tiene un parche listo.

Si tu web está en	Actualiza a	Fallos corregidos
7.0	7.0.5	los 11
6.9	6.9.8	los 11
6.8	6.8.9	los 11
6.7	6.7.8	los 11
de 6.6 a 5.9	de la 6.6.8 a la 5.9.17	10 de 11
de 5.8 a 5.6	de la 5.8.16 a la 5.6.20	9 de 11
de 5.5 a 5.3	de la 5.5.21 a la 5.3.24	8 de 11
de 5.2 a 4.8	de la 5.2.27 a la 4.8.31	7 de 11
4.7	4.7.36	6 de 11
4.6 y anteriores	sin parche	ya no tienen soporte

Dicho esto, el proyecto lo repite en cada entrega y tiene razón: la única versión realmente soportada es la última. El parche en una rama antigua es un puente para ganar tiempo, no un sitio donde quedarse a vivir.

Qué cambia además de la seguridad

Junto a las once correcciones hay 17 errores resueltos en el core y los del editor de bloques, donde por cierto las cuentas oficiales no cuadran: el anuncio habla de 19 correcciones y la página de documentación de la versión cuenta 21. Pequeña imprecisión, pero da idea de lo comprimido que ha sido el trabajo en esta entrega, cerrada por más de 90 personas en pocas semanas.

Los archivos tocados son trece, y leerlos es la forma más rápida de saber dónde mirar si algo de tu web se comporta raro después de actualizar: formatting.php (ahí vive wpautop), el procesador de etiquetas de la API HTML, el controlador de comentarios de la API REST, el servidor XML-RPC, la gestión de las imágenes de cabecera, theme.php y algunos archivos del área de administración. Si usas un plugin que filtra comentarios o que manipula el HTML de salida, ese es el primer sitio donde mirar.

La próxima versión principal será la 7.2, prevista para diciembre.

Mi opinión sobre este ritmo de parches

Desde que llevo webs de clientes, el ritmo de parches de seguridad de WordPress nunca había sido este. Cuatro entregas de seguridad en pocas semanas no son la señal de que WordPress se haya vuelto menos seguro, son la señal de que se ha acabado la época en la que encontrar un fallo exigía semanas de trabajo humano. Un modelo que lee código hace en una tarde lo que antes le llevaba meses a un investigador, y de ahí que los avisos hayan pasado de treinta a setecientos setenta y tres al mes.

La conclusión práctica que saco, y que les digo a los clientes: dejar de pensar en la actualización como un evento y empezar a tratarla como una rutina. Actualizaciones automáticas de las menores activas, copia diaria que alguien haya probado a restaurar al menos una vez, staging para las webs que facturan y una persona que mire el sitio cuando sale un parche importante. Quien tiene esto montado ha leído esta noticia y no ha tenido que hacer nada. Quien no, hoy tiene una ventana abierta con un comentario dentro esperando que lo apruebes.

Una nota sobre los comentarios, ya que son la puerta de entrada de esta historia: si en tu web no los lee ni los escribe nadie desde hace años, cerrarlos es una decisión de seguridad, no una renuncia. Menos superficie expuesta, menos cosas que actualizar con prisas.

Conclusión

La 7.1.1 es una actualización para hacer ya, no para apuntar en la lista del mes que viene. El fallo de los comentarios es el único explotable sin tener cuenta, y en una web con comentarios abiertos es una puerta entornada. Todos los demás necesitan un usuario registrado, pero tres se explotan con permisos de colaborador, que es el rol que se reparte con más alegría.

Actualiza desde el escritorio, comprueba que las actualizaciones automáticas estén realmente activas y, si tu web es importante, dedica diez minutos a revisar comentarios y usuarios. Después vuelve a trabajar, que es lo que cuenta.

Preguntas frecuentes

¿Tengo que actualizar aunque tenga los comentarios cerrados?

Sí. Con los comentarios cerrados el fallo más grave no te afecta, pero quedan diez correcciones que tocan permisos, API REST, XML-RPC y temas. Si en la web hay más usuarios además de ti, algunos de esos fallos se explotan con los permisos más bajos que existen.

¿Cómo sé qué versión tengo ahora?

Entra en el escritorio y mira abajo a la derecha en la pantalla principal, o abre Herramientas y luego Salud del sitio, pestaña Información. Desde terminal es wp core version.

¿Puedo romper la web al actualizar?

Una actualización menor cambia muy poco y el riesgo es bajo: aquí se han tocado trece archivos. Los problemas suelen venir de plugins o temas viejos que ya no eran compatibles ni antes. Con copia de seguridad y staging el riesgo es mínimo.

¿Bastan las actualizaciones automáticas?

Para las menores como esta sí, siempre que estén realmente activas. No cubren plugins ni temas, salvo que los hayas configurado uno a uno, y ahí es donde nace la mayoría de webs comprometidas.

¿Un plugin de seguridad me protege igual?

En parte. Un firewall puede bloquear payloads conocidos antes de que lleguen a la web, pero el fallo sigue en el código hasta que actualizas. El plugin da tiempo, no sustituye al parche.

¿Qué pasa si me quedo en la 7.0?

La 7.0 es vulnerable a los once fallos. Existe la 7.0.5 que los corrige, así que al menos esa hay que instalarla, pero la rama antigua solo recibe parches de seguridad y ninguna de las correcciones funcionales.

¿Por qué salen tantas actualizaciones de seguridad últimamente?

Porque las vulnerabilidades se encuentran mucho más rápido que antes: los avisos al programa bug bounty de WordPress han pasado de 20-30 al mes a 773 en agosto, con varias empresas de inteligencia artificial entre quienes reportan. El código no ha empeorado, ha cambiado quién lo mira.

Lee también:
Elementor MCP: qué es y qué puede hacer de verdad ·
Elementor Editor V4 ·
Core Web Vitals en 2026

Fuentes

WordPress.org en español, 17 de septiembre de 2026: el aviso oficial traducido.
WordPress.org, anuncio original: la lista de los once avisos y sus créditos.
Documentación de la versión 7.1.1: archivos modificados, ramas actualizadas y cuántos fallos afectan a cada una.
Patchstack: el análisis técnico del fallo de wpautop, con CVE y puntuación CVSS.
The Repository, 18 de septiembre de 2026: los créditos a las empresas de IA y las cifras del bug bounty.
Programa HackerOne de WordPress: donde llegan los avisos de vulnerabilidades.

Daniele Forciniti

Soy Daniele Forciniti, un experto en diseño web y SEO con más de 10 años de experiencia y diversas certificaciones profesionales. Estoy especializado en HTML y CSS, y utilizo CMS como WordPress. Soy el mayor experto en España en WIX y WIX Studio, y también me encargo del posicionamiento web SEO en buscadores y de marketing digital. Me apasiona mi trabajo y me actualizo constantemente para ofrecer soluciones innovadoras y de alta calidad a mis clientes.