WordPress 7.1.1 corrige 11 vulnerabilidades y WordPress recomienda actualizar de inmediato
Fecha efectiva / observada:
Qué ha cambiado
WordPress 7.1.1 ya está disponible como actualización de mantenimiento y seguridad. Corrige 11 vulnerabilidades, además de errores de Core y del editor de bloques, y el propio proyecto recomienda actualizar los sitios inmediatamente. QUÉ HA CAMBIADO WordPress publicó la versión 7.1.1 el 17 de septiembre de 2026. La versión combina: - 17 correcciones de errores en Core; - correcciones en el Block Editor; - 11 correcciones de seguridad. Hay una discrepancia entre dos fuentes oficiales de WordPress sobre el número de correcciones del editor de bloques: - el anuncio de WordPress News habla de 19; - la página HelpHub de la versión 7.1.1 habla de 21. RadarAbierto no debe ocultar esa diferencia ni elegir una cifra como definitiva sin aclararlo. Lo importante para seguridad es que ambas fuentes coinciden en las 11 correcciones de seguridad y en la recomendación de actualizar inmediatamente. LAS 11 CORRECCIONES DE SEGURIDAD WordPress enumera 11 problemas corregidos. 1. XSS almacenado en `wpautop()` Un visitante no autenticado podía introducir contenido que terminara ejecutando script bajo determinadas condiciones, sujeto a aprobación del comentario. 2. Salida de comentarios HTML mediante HTML API `set_modifiable_text()` podía permitir romper el contexto de un comentario HTML mediante determinadas secuencias de cierre. 3. XSS almacenado en imágenes de cabecera Afectaba a algunos temas que admiten cabeceras personalizadas. 4. URL especialmente construida capaz de instalar y previsualizar un tema Una URL manipulada podía hacer que WordPress instalara y previsualizara automáticamente un tema inactivo procedente de WordPress.org. 5. Activación de plugins Network-only en Multisite Un administrador de sitio podía llegar a activar a nivel de red un plugin instalado que debía ser exclusivo de Network Admin. 6. Path traversal autenticado en REST API Templates Controller Un usuario autenticado podía aprovechar una debilidad de recorrido de rutas en el controlador de plantillas de la REST API. 7. XML-RPC y `customize_changeset` Era posible publicar entradas de tipo `customize_changeset` evitando determinadas comprobaciones asociadas a la capacidad `edit_css`. 8. Sobrescritura arbitraria de entradas por Contributor+ Un usuario con nivel Contributor o superior podía sobrescribir contenido de entradas en condiciones afectadas. 9. Filtración del título de una entrada privada padre Faltaba una comprobación `read_post` en `attachment_submitbox_metadata()`, lo que podía exponer el título de una entrada privada relacionada. 10. Divulgación de slugs de borradores y entradas pendientes Un usuario Contributor+ podía obtener slugs de contenido que todavía no debía ser público. 11. Reparentado de comentarios y notas Cualquier usuario autenticado podía cambiar el padre de comentarios, incluidas notas. NO TODOS LOS FALLOS TIENEN LAS MISMAS PRECONDICIONES La lista incluye problemas muy diferentes. Algunos requieren: - que el atacante esté autenticado; - un nivel mínimo de permisos; - una instalación Multisite; - un tema con determinada funcionalidad; - aprobación de comentarios; - o un flujo concreto de WordPress. Otros tienen una superficie más amplia. Por eso no conviene resumir la versión únicamente como “11 vulnerabilidades críticas”. WordPress no presenta las 11 con una única severidad común y RA no debe inventarla. La conclusión práctica es más sencilla: se trata de una release de seguridad oficial y WordPress recomienda actualizar. UNA DE LAS CORRECCIONES AFECTA A VISITANTES NO AUTENTICADOS El XSS relacionado con `wpautop()` es especialmente relevante porque WordPress lo describe como explotable por un visitante no autenticado, aunque el escenario está sujeto a aprobación del comentario. Esto no significa que cualquier sitio pueda ser comprometido de forma automática. La configuración de comentarios y el flujo de moderación influyen. Pero sí elimina la idea de que todas las correcciones de 7.1.1 necesiten una cuenta previa. ACTUALIZACIÓN DE TEMAS MEDIANTE UNA URL MANIPULADA Otra corrección destaca porque afecta al flujo de temas. WordPress indica que una URL especialmente construida podía provocar la instalación y previsualización de un tema inactivo desde WordPress.org. Esto no equivale a instalar cualquier código arbitrario desde cualquier origen. La descripción oficial limita el caso a temas de WordPress.org y a ese flujo concreto. Aun así, es una buena razón para no tratar una actualización de mantenimiento como algo menor. ANTHROPIC REPORTÓ DOS DE LOS PROBLEMAS WordPress atribuye a Anthropic dos de las vulnerabilidades: - path traversal autenticado en REST API Templates Controller; - sobrescritura arbitraria de entradas por Contributor+. Esto es relevante para la evolución que RA ya está siguiendo sobre IA aplicada a seguridad. Pero el mérito de la corrección corresponde al proceso completo: detección → reporte responsable → validación → parche → release Que una vulnerabilidad haya sido reportada por una IA o por una organización que utiliza IA no convierte automáticamente el hallazgo en correcto hasta que el equipo responsable lo valida y corrige. BACKPORTS: WORDPRESS TAMBIÉN CORRIGE RAMAS ANTIGUAS WordPress ha publicado correcciones para múltiples ramas antiguas afectadas. La documentación oficial indica: - WordPress 7.0: afectado por las 11 → 7.0.5; - WordPress 6.9: afectado por las 11 → 6.9.8; - WordPress 6.8: afectado por las 11 → 6.8.9; - WordPress 6.7: afectado por las 11 → 6.7.8; - WordPress 6.6 a 6.0: afectados por 10 de las 11; - WordPress 5.9: 10 de las 11; - WordPress 5.8 a 5.6: 9 de las 11; - WordPress 5.5 a 5.3: 8 de las 11; - WordPress 5.2 a 4.8: 7 de las 11; - WordPress 4.7: 6 de las 11. WordPress 4.6 y anteriores ya no reciben actualizaciones de seguridad. UN MATIZ IMPORTANTE SOBRE VERSIONES ANTIGUAS Que WordPress publique backports de seguridad para ramas antiguas no significa que esas ramas tengan soporte completo. La política oficial recuerda que solo la serie más reciente está activamente mantenida. Los backports hacia versiones antiguas se realizan como cortesía y no tienen un periodo de soporte garantizado. Por tanto: “mi versión antigua recibió este parche” no significa “puedo permanecer indefinidamente en esa rama”. QUÉ DEBE HACER UN USUARIO NORMAL Si administras un sitio WordPress y no tienes un proceso técnico complejo: 1. Haz una copia de seguridad reciente. 2. Comprueba si la actualización automática ya se ha aplicado. 3. Si no, entra en Escritorio → Actualizaciones. 4. Actualiza a WordPress 7.1.1. 5. Revisa portada, acceso, formularios, editor y funciones principales. 6. Comprueba plugins y tema si observas cualquier regresión. La recomendación oficial es actualizar inmediatamente. QUÉ DEBE HACER UNA EMPRESA O UN SITIO CRÍTICO “Actualizar inmediatamente” no significa saltarse todos los controles. En un entorno crítico conviene reducir al mínimo el tiempo de exposición sin convertir la actualización en un cambio ciego. Un flujo razonable es: BACKUP → DEV o entorno de prueba representativo → STAGING → pruebas esenciales → PRODUCCIÓN → verificación posterior El objetivo es hacerlo con prioridad, no retrasarlo durante semanas. Especialmente conviene comprobar: - login y roles; - editor; - REST API; - XML-RPC si está habilitado; - Multisite; - temas con cabeceras personalizadas; - comentarios y moderación; - creación/edición de entradas; - plugins que interactúan con plantillas o permisos; - caché y CDN; - errores PHP y logs. SI TIENES ACTUALIZACIONES AUTOMÁTICAS WordPress indica que, en sitios compatibles con actualizaciones automáticas en segundo plano, el proceso puede comenzar automáticamente. No asumas que eso significa que todos tus sitios ya están actualizados. Verifica la versión real instalada. En instalaciones administradas por terceros, hosting gestionado o plataformas con ventanas propias de actualización, el despliegue puede depender de sus políticas. WORDPRESS 7.1.1 ES UNA RELEASE DE CICLO CORTO WordPress describe 7.1.1 como una short-cycle release. La siguiente versión mayor prevista es WordPress 7.2, actualmente planificada para diciembre de 2026. Por tanto, 7.1.1 no debe verse como una versión de soporte prolongado. Su papel inmediato es corregir seguridad y mantenimiento dentro de la serie 7.1. QUÉ SABEMOS SOBRE LOS CAMBIOS DE MANTENIMIENTO Además de seguridad, la versión incluye correcciones en Core y Block Editor. Las dos fuentes oficiales no coinciden exactamente en el total de correcciones del editor: - WordPress News: 19; - HelpHub: 21. Este desacuerdo no afecta a la recomendación de seguridad, pero sí es un ejemplo de por qué RA debe conservar la procedencia exacta de cada cifra. Si WordPress corrige una de las páginas posteriormente, RA debe actualizar esta historia y dejar constancia del cambio. ARCHIVOS DE CORE MODIFICADOS HelpHub enumera cambios en archivos relacionados con: - AJAX; - cabeceras personalizadas; - medios; - plugins; - entradas; - temas; - XML-RPC; - REST API; - formatting; - HTML API; - comentarios. No se revisó ningún paquete externo según esa documentación. Esto ayuda a entender que la release toca varias superficies de seguridad de WordPress Core. POR QUÉ ESTA NOTICIA IMPORTA A RADARABIERTO Esta señal no es solo una noticia sobre WordPress. Es un buen ejemplo de cómo debe trabajar RA: FUENTE OFICIAL → detectar una release de seguridad INVESTIGAR → abrir documentación completa CONTRASTAR → descubrir que dos fuentes oficiales difieren en 19 vs 21 correcciones del Block Editor EXPLICAR → separar vulnerabilidades por precondiciones y no llamarlas a todas “críticas” AYUDAR → convertir el anuncio en un plan práctico de actualización SEGUIR → comprobar si WordPress corrige la discrepancia, aparecen CVE, análisis técnicos o problemas posteriores a la actualización Eso es más útil que reproducir el primer párrafo de WordPress News. A QUIÉN PUEDE INTERESAR Si tienes una web WordPress: debes comprobar que estás en una versión corregida. Si administras varias webs: prioriza inventario y despliegue controlado. Si trabajas en hosting: revisa la velocidad de despliegue de 7.1.1 y de los backports. Si desarrollas plugins o temas: prueba compatibilidad y observa regresiones. Si trabajas en seguridad: interesa seguir la publicación de detalles técnicos, CVE y explotación real. Si mantienes versiones antiguas: los backports reducen riesgo inmediato, pero no sustituyen un plan de actualización de rama. QUÉ DEBES COMPROBAR DESPUÉS DE ACTUALIZAR Después de instalar 7.1.1: 1. Confirma que WordPress muestra realmente la versión 7.1.1. 2. Revisa el registro de errores. 3. Prueba login y logout. 4. Crea y edita una entrada de prueba. 5. Prueba formularios y comentarios si existen. 6. Comprueba las funciones críticas del tema. 7. Revisa endpoints o integraciones REST importantes. 8. Si usas Multisite, prueba administración de red. 9. Si dependes de XML-RPC, valida el flujo. 10. Conserva evidencia de versión, fecha y resultado de las pruebas. RECURSOS Anuncio oficial: https://wordpress.org/news/2026/09/wordpress-7-1-1-maintenance-and-security-release/ Documentación de WordPress 7.1.1: https://wordpress.org/documentation/wordpress-version/version-7-1-1/ Archivo de versiones: https://wordpress.org/download/releases/ Política de versiones soportadas: https://wordpress.org/documentation/article/supported-versions/ QUÉ VIGILARÁ RADARABIERTO RA debe seguir: - publicación de CVE o identificadores adicionales; - detalles técnicos de las 11 vulnerabilidades; - explotación activa si llega a documentarse; - corrección de la discrepancia 19 vs 21 del Block Editor; - problemas de compatibilidad posteriores; - regresiones de 7.1.1; - versiones 7.1.x posteriores; - evolución de los backports; - instalaciones que sigan en ramas no mantenidas; - si aparecen pruebas de concepto públicas; - cambios en recomendaciones de WordPress; - calendario y desarrollo de WordPress 7.2. Esta señal debe mantenerse como historia viva. El punto de partida es una release oficial de seguridad; el valor de RA estará en seguir qué vulnerabilidades resultan explotables en la práctica, qué cambia después del despliegue y si WordPress modifica o amplía la información publicada.
Por qué puede importarte
WordPress 7.1.1 corrige 11 fallos de seguridad en distintas superficies de Core y el propio proyecto recomienda desplegarla inmediatamente. Además, RA ha detectado una discrepancia entre dos fuentes oficiales sobre si el Block Editor incluye 19 o 21 correcciones, lo que merece seguimiento.
Cómo ha evolucionado
Primer registro en RadarAbierto: 18/09/2026. Estado actual: actual. Añadiremos los cambios posteriores sin borrar este registro.
Qué todavía no sabemos
WordPress News indica 19 correcciones del Block Editor y HelpHub indica 21; ambas fuentes oficiales coinciden en 17 correcciones de Core y 11 de seguridad. WordPress no asigna una severidad única a las 11 vulnerabilidades. No se debe presentar toda la release como '11 fallos críticos' ni asumir explotación activa.
Seguir el contexto
La señal conserva procedencia y relaciones internas para que puedas comprobar el origen y explorar cambios relacionados.
Esta ficha verificable es igual para todos. Puedes indicar si te afecta, si no se entiende, si quieres seguirla o si no te interesa. Para que seguir u ocultar cambie solo tu selección, crea Mi Radar.