WordPress 7.1.1 corrige 11 fallos: cómo verificar una cartera

Respuesta corta: WordPress 7.1.1 es una actualización de seguridad y mantenimiento que corrige 11 fallos. Si gestionas varias webs, no basta con esperar a las actualizaciones automáticas: comprueba la versión efectiva de cada sitio, identifica las ramas antiguas que recibieron backport, revisa la exposición de comentarios y administradores, y cierra la tarea solo cuando toda la cartera tenga una versión corregida o una excepción documentada.

La actualización se publicó el 17 de septiembre de 2026. WordPress recomienda instalarla de inmediato. Esta guía está dirigida a agencias, freelancers y equipos de mantenimiento; no sustituye una investigación forense y no presupone que un sitio sin actualizar esté comprometido.

Publicado y revisado el 21 de septiembre de 2026.

Qué corrige WordPress 7.1.1

La nota oficial de WordPress 7.1.1 incluye 17 correcciones en Core, cambios en el editor de bloques y 11 correcciones de seguridad. Entre estas últimas hay problemas de XSS almacenado, autorización, sobrescritura de entradas, exposición de información, recorrido de rutas, XML-RPC, Multisite y una URL manipulada capaz de instalar y previsualizar un tema de WordPress.org.

Dos rutas merecen especial atención operativa:

• Comentarios públicos: CVE-2026-93485 describe un XSS almacenado no autenticado en el formateo de párrafos. El registro le asigna CVSS 7.1 y confirma que requiere interacción de un usuario. La nota oficial añade que el contenido está sujeto a aprobación de comentarios.
• Navegación de administradores: una URL especialmente preparada podía abusar del flujo de instalación y previsualización de temas. El análisis técnico de Patchstack sobre Click2Shell explica que la cadena requiere que un administrador autenticado cargue el enlace y, para llegar a instalación de tema, que el sitio permita modificar archivos.

Evidencia frente a interpretación: WordPress confirma los 11 fallos y recomienda actualizar; el registro CVE y Patchstack documentan las condiciones anteriores. El orden de revisión que propone este artículo es criterio editorial para operar una cartera, no una instrucción oficial de WordPress.

Qué versiones debes buscar en la cartera

La documentación oficial de la versión 7.1.1 detalla los backports. Solo la rama más reciente recibe soporte activo, aunque WordPress publicó correcciones para ramas anteriores como cortesía.

Rama observada	Versión corregida	Decisión práctica
7.1	7.1.1	Actualizar a 7.1.1 y verificar el sitio.
7.0	7.0.5	Aplicar el backport; planificar la subida a la rama actual.
6.9	6.9.8	Aplicar el backport; revisar por qué el sitio permanece en una rama antigua.
6.8	6.8.9	Aplicar el backport y registrar la excepción de compatibilidad.
6.7	6.7.8	Aplicar el backport y tratar la antigüedad como deuda operativa.
4.7–6.6	Depende de la rama	Consultar la tabla oficial; no asumir que el último parche de otra rama sirve.
4.6 o anterior	Sin actualización de seguridad	Aislar, migrar o retirar; documentar el riesgo residual.

Un inventario que solo diga «WordPress 6.x» no permite cerrar esta tarea. Necesitas la versión completa y la hora de la última observación. Si el sitio no comunica o el dato está desactualizado, su estado es desconocido, no «correcto».

Prioriza por condiciones, no por el número 11

No todos los fallos comparten el mismo requisito ni el mismo impacto. Para decidir qué revisar primero, cruza versión y exposición:

Condición	Prioridad editorial	Qué comprobar
Comentarios públicos y equipo que aprueba comentarios	Alta	Versión corregida, política de moderación y comentarios aprobados durante la ventana.
Administradores que reciben enlaces externos y sitio con instalación de temas habilitada	Alta	Versión, privilegios, eventos de instalación/activación y navegación sospechosa comunicada por el equipo.
Multisite o uso activo de XML-RPC	Alta según contexto	Versión, roles, cambios de red, publicaciones y configuración relacionada.
Staging aislado y sin usuarios externos	Menor, no nula	Actualizar dentro de la ventana definida y evitar que quede olvidado.
Sitio sin telemetría reciente	Indeterminada	Recuperar observabilidad antes de declarar que está actualizado.

Juicio editorial: el sitio más importante no siempre es el primero en el listado. Empieza por la intersección de versión vulnerable, superficie expuesta, privilegio y falta de evidencia. Un WooCommerce sin comentarios puede requerir acción urgente por su impacto de negocio, mientras que un blog con comentarios abiertos puede encabezar la revisión por la ruta de entrada documentada.

Checklist para verificar varias webs

1. Congela el denominador: exporta la lista completa de producción, staging y sitios en mantenimiento.
2. Lee la versión efectiva: no uses una promesa de autoactualización como sustituto del dato posterior al despliegue.
3. Compara por rama: exige 7.1.1, 7.0.5, 6.9.8 o el backport exacto que corresponda.
4. Separa excepciones: registra propietario, motivo, compensaciones y fecha de caducidad.
5. Prueba una muestra: valida frontend, login, comentarios, editor y funciones críticas del cliente.
6. Revisa señales relevantes: altas de administradores, instalaciones o activaciones de temas, cambios de contenido, acciones XML-RPC y comentarios aprobados en la ventana de exposición.
7. Busca huecos: una web que dejó de reportar no cuenta como actualizada ni como limpia.
8. Cierra con evidencia: conserva versión observada, hora, prueba funcional, incidencias y riesgo residual.

Si necesitas formalizar ese cierre, usa el marco de señal, alcance, decisión, acción, verificación y riesgo residual. Para los sitios que no devuelven datos recientes, aplica primero la guía para detectar huecos de monitorización en una cartera WordPress.

Actualizar reduce la exposición; no demuestra ausencia de incidente

Una versión corregida cierra las rutas conocidas incluidas en ese parche. No demuestra por sí sola que nadie las aprovechara antes, que el sitio esté libre de persistencia o que todos los eventos necesarios sigan disponibles. Tampoco convierte cualquier anomalía anterior en explotación confirmada.

En el momento de esta revisión, CVE-2026-93485 no figura en el catálogo KEV de CISA y el enriquecimiento de CISA en el registro CVE marca explotación como «none». Eso significa que estas fuentes no aportan evidencia de explotación conocida en ese momento; no prueba que la explotación sea imposible ni que ningún sitio haya sido atacado.

Escala a investigación si encuentras administradores inesperados, temas instalados sin cambio autorizado, publicaciones sobrescritas, actividad XML-RPC anómala, comentarios sospechosos ya aprobados o diferencias entre la versión inventariada y la observada.

Dónde encaja Vulnity y cuáles son sus límites

Vulnity centraliza señales de seguridad de varios WordPress, monitoriza actividad sospechosa, genera alertas en tiempo real y permite bloquear automáticamente IPs maliciosas. Esa vista común ayuda a reducir saltos entre paneles y a aplicar un flujo consistente de revisión y respuesta.

Vulnity no detecta CVEs ni identifica plugins, temas o versiones de WordPress vulnerables. Tampoco demuestra que WordPress 7.1.1 se haya instalado, sustituye el inventario de versiones, un WAF, un escáner de malware, backups probados, los logs del hosting o el análisis forense. La versión debe verificarse con una fuente fiable del propio sitio o de su plataforma de gestión.

Conclusión: convierte la actualización en una comprobación de cobertura

WordPress 7.1.1 merece prioridad porque corrige 11 problemas de seguridad y afecta a ramas muy extendidas. Pero el trabajo de una agencia no termina al pulsar «actualizar»: termina cuando puede demostrar qué sitios estaban en alcance, cuál es su versión corregida, qué excepciones siguen abiertas y qué señales revisó.

Haz primero el inventario completo, aplica el backport correcto por rama y trata los sitios silenciosos como cobertura desconocida. Después prueba funciones críticas y conserva evidencia. Esa disciplina evita dos errores opuestos: convertir la publicación en alarma sin contexto o dar por segura una cartera solo porque la actualización automática estaba habilitada.