WordPress 7.1.2 corrige una vulnerabilidad crítica: qué riesgo existía y por qué actualizar
Una actualización de WordPress puede parecer una notificación más dentro del Escritorio, pero algunas versiones no incorporan simplemente mejoras visuales o pequeñas correcciones: cierran vulnerabilidades que ya fueron identificadas, documentadas y corregidas por el equipo de seguridad.
El 22 de septiembre de 2026 WordPress publicó la versión 7.1.2, una actualización dedicada a resolver una vulnerabilidad clasificada oficialmente como crítica. El equipo de WordPress recomienda actualizar los sitios inmediatamente.
La publicación llega apenas cinco días después de WordPress 7.1.1, que ya había solucionado once problemas de seguridad junto con decenas de correcciones en Core y el editor de bloques. En menos de una semana, dos actualizaciones volvieron a demostrar algo fundamental para cualquier sitio administrado profesionalmente: la seguridad no termina cuando una web se publica.
En esta nota de byteStudio Argentina analizamos qué ocurrió con WordPress 7.1.2, qué otros problemas acababa de corregir la versión 7.1.1 y por qué un mantenimiento responsable debe contemplar Core, plugins, temas, infraestructura y copias de seguridad como partes de un mismo sistema.
Respuestas rápidas sobre la actualización de seguridad
Los datos esenciales antes de revisar nuestra instalación.
Una actualización publicada específicamente para cerrar una falla crítica
WordPress 7.1.2 fue publicada oficialmente el 22 de septiembre de 2026. A diferencia de una versión mayor cargada de nuevas funciones, esta publicación tiene un objetivo muy concreto: corregir una vulnerabilidad de seguridad de severidad crítica.
El propio proyecto WordPress recomienda que los sitios sean actualizados inmediatamente. Las instalaciones compatibles con las actualizaciones automáticas en segundo plano también pueden iniciar el proceso automáticamente.
La vulnerabilidad recibió la referencia CVE-2026-87902 y también cuenta con un advisory público identificado como GHSA-7hp8-65ch-5whp.
La resolución de plantillas podía alcanzar archivos PHP fuera del tema activo
Según la explicación oficial, un atacante no autenticado podía, bajo determinadas condiciones, manipular el proceso de resolución de plantillas de una página para provocar la inclusión de un archivo PHP local legible ubicado fuera de los directorios del tema activo.
La importancia del problema radica en el resultado potencial: si además se cumplen las condiciones necesarias en el servidor y el tema, esa inclusión puede desembocar en ejecución remota de código, conocida habitualmente como RCE.
Una RCE es una categoría especialmente delicada porque implica que código no previsto pueda ejecutarse en el servidor. No todos los escenarios de la vulnerabilidad terminaban necesariamente en esa consecuencia, pero la posibilidad explica la severidad asignada al problema.
Cinco días antes ya se habían corregido once problemas de seguridad
WordPress 7.1.2 no aparece en forma aislada. El 17 de septiembre se había publicado WordPress 7.1.1, una actualización de mantenimiento y seguridad que incorporó 17 correcciones en Core, 19 en el editor de bloques y once correcciones específicamente relacionadas con seguridad.
Las vulnerabilidades cubrían diferentes componentes y niveles de permisos. Entre ellas se documentaron problemas de Cross-Site Scripting almacenado, traversal de rutas, controles de autorización insuficientes, exposición de determinada información privada y acciones que usuarios autenticados podían realizar sin los permisos previstos.
| Tipo de problema | Qué había documentado WordPress |
|---|---|
| XSS almacenado | Problemas en wpautop() y determinados temas compatibles con encabezados personalizados. |
| Path Traversal | Una incidencia autenticada en el controlador REST de plantillas. |
| XML-RPC | Posibilidad de publicar determinados customize_changeset eludiendo una comprobación relacionada con edit_css. |
| Autorización | Diferentes situaciones donde un usuario podía realizar o consultar acciones fuera del permiso esperado. |
| Información privada | Exposición de determinados títulos o slugs que debían permanecer restringidos. |
Uno de los casos resulta especialmente interesante porque involucra XML-RPC. Desactivar esa interfaz cuando no es necesaria puede formar parte de una estrategia de reducción de superficie, pero esta actualización demuestra por qué el hardening y los parches cumplen funciones diferentes: cerrar un endpoint no reemplaza mantener actualizado el software.
Un parche transforma una vulnerabilidad desconocida en un riesgo que ya podemos corregir
Una vulnerabilidad puede permanecer durante un tiempo sin que el propietario del sitio tenga conocimiento de ella. Cuando el equipo responsable recibe un reporte, investiga el problema y publica una corrección, la situación cambia: ya existe una versión que elimina o mitiga la falla.
Además, una vez publicada la información de seguridad, también comienza a existir documentación pública sobre la vulnerabilidad. WordPress señala precisamente este aspecto en su documentación de hardening: cuando se publica una actualización de seguridad, permanecer en versiones anteriores aumenta la exposición porque la existencia del problema ya es conocida.
Por eso una estrategia de seguridad que mantiene firewalls, URLs ocultas y contraseñas robustas pero posterga indefinidamente las actualizaciones sigue dejando una capa fundamental sin resolver.
Core actualizado no alcanza si plugins, temas o servidor permanecen abandonados
WordPress no funciona únicamente con su núcleo. Una instalación real combina Core, plugins, temas, PHP, servidor web, base de datos y servicios externos. Cada componente agrega funcionalidades, pero también código que debe mantenerse.
La documentación oficial de WordPress identifica el mantenimiento actualizado de WordPress, plugins y temas como una de las medidas más importantes de seguridad. También recomienda seleccionar extensiones que continúen recibiendo mantenimiento.
Correcciones de seguridad, estabilidad y compatibilidad del núcleo.
Extensiones que agregan código y requieren mantenimiento independiente.
También pueden contener lógica, plantillas y dependencias vulnerables.
El entorno que ejecuta WordPress también necesita versiones soportadas y actualizadas.
Actualizar tampoco significa instalar cualquier versión sin control. Un mantenimiento profesional debe conocer las dependencias del sitio, detectar plugins abandonados y disponer de una estrategia para responder si una actualización produce una incompatibilidad.
Actualizar rápido no significa actualizar a ciegas
Frente a una actualización crítica, reducir el tiempo de exposición es importante. Pero también necesitamos asegurarnos de que el sitio pueda recuperarse si aparece un problema de compatibilidad.
Antes de actualizar una instalación importante, conviene disponer de una copia reciente de archivos y base de datos, asegurarse de que sea posible restaurarla y conocer el estado previo del sitio.
- Confirmar qué versión está instalada.
- Verificar que existe una copia reciente recuperable.
- Revisar plugins y temas pendientes.
- Aplicar la actualización de seguridad.
- Comprobar frontend, panel, formularios y funciones críticas.
- Revisar registros y estado del sitio después del cambio.
En sitios complejos puede utilizarse además un entorno de staging para comprobar compatibilidad. Sin embargo, cuando se publica una vulnerabilidad crítica, el proceso de validación no debería convertirse en una excusa para mantener producción expuesta durante períodos innecesariamente largos.
Las actualizaciones automáticas reducen tiempos, pero también deben ser supervisadas
WordPress admite actualizaciones automáticas en segundo plano para determinadas versiones del núcleo y permite habilitar actualizaciones automáticas individualmente para plugins y temas.
Esta capacidad puede reducir significativamente el tiempo entre la publicación de un parche y su instalación. En materia de seguridad, esa reducción es valiosa.
Sin embargo, automatizar no significa desentenderse. WordPress recomienda mantener backups y verificar que las tareas automáticas funcionen correctamente. La pantalla Salud del sitio incluso puede advertir cuando los procesos de actualización en segundo plano presentan problemas.
El mantenimiento reduce riesgos antes de que una notificación se transforme en una emergencia
Un sitio WordPress puede funcionar aparentemente bien durante meses mientras acumula actualizaciones pendientes. Desde la perspectiva del visitante, nada parece haber cambiado. Desde la perspectiva de seguridad, en cambio, el código puede estar conservando vulnerabilidades ya corregidas por sus desarrolladores.
Por eso el mantenimiento profesional no debería comenzar cuando aparece una pantalla en blanco o cuando una web ya fue comprometida. Consiste en revisar periódicamente versiones, backups, logs, disponibilidad, certificados, usuarios, plugins y comportamiento del servidor.
La publicación consecutiva de WordPress 7.1.1 y 7.1.2 resulta un ejemplo claro. Las vulnerabilidades no desaparecen porque un sitio tenga pocas visitas o porque nunca haya sufrido un incidente anterior. La corrección se encuentra disponible y corresponde integrarla al ciclo habitual de mantenimiento.
Preguntas frecuentes sobre WordPress 7.1.2 y las actualizaciones de seguridad
¿WordPress 7.1.2 es una actualización de seguridad?
Sí. Fue publicada el 22 de septiembre de 2026 para corregir una vulnerabilidad clasificada como crítica.
¿Qué tipo de problema corrige?
Bajo determinadas condiciones, un atacante no autenticado podía manipular la resolución de plantillas para incluir un archivo PHP local legible fuera del tema activo, con posibilidad de ejecución remota de código si se cumplían requisitos adicionales.
¿Todos los sitios WordPress eran explotables?
No. La documentación oficial indica que debían cumplirse precondiciones relacionadas con el servidor y el tema activo. Aun así, WordPress recomienda actualizar inmediatamente.
¿Por qué hubo dos actualizaciones de seguridad tan cercanas?
WordPress 7.1.1, publicada el 17 de septiembre, corrigió once problemas de seguridad. El 22 de septiembre se publicó 7.1.2 para resolver una vulnerabilidad crítica adicional.
¿Actualizar WordPress evita todos los hackeos?
No. El mantenimiento actualizado corrige vulnerabilidades conocidas, pero la seguridad también depende de plugins, temas, hosting, credenciales, permisos, controles de acceso, desarrollo seguro y recuperación.
¿Hay que hacer un backup antes de actualizar?
Es recomendable disponer de una copia reciente y recuperable. El backup permite restaurar el sitio si aparece una incompatibilidad o un problema durante la actualización.
Conclusión: cuando el parche ya existe, mantener una versión vulnerable deja de tener sentido
WordPress 7.1.2 no es una actualización que debamos instalar por tener el número más reciente. Corrige una vulnerabilidad crítica documentada y publicada por el propio equipo de seguridad.
La versión 7.1.1, publicada apenas unos días antes, ya había resuelto otros once problemas. Ambas versiones muestran por qué un sitio necesita mantenimiento después de haber sido desarrollado.
Firewalls, autenticación de dos factores, restricciones de IP y hardening aportan capas valiosas. Pero ninguna de ellas convierte en innecesarios los parches del software. Las medidas se complementan.
Mantener WordPress, plugins, temas y servidor actualizados, disponer de backups comprobados y revisar periódicamente el funcionamiento del sitio permite reducir riesgos conocidos y responder con mayor rapidez cuando aparece una nueva vulnerabilidad.
Para conocer las medidas generales de prevención, consultá nuestra guía sobre seguridad WordPress y reducción del riesgo de hackeos.
Si necesitás profundizar en controles técnicos de acceso, revisá nuestra investigación sobre blindaje de wp-admin, XML-RPC, restricciones por IP y respuestas HTTP 403.
WordPress.org: WordPress 7.1.2 Release, 22 de septiembre de 2026.
WordPress.org: WordPress 7.1.1 Maintenance and Security Release.
WordPress.org: documentación oficial para actualizar WordPress.
WordPress Developer Resources: Hardening WordPress.
WordPress.org: actualizaciones automáticas de plugins y temas.
El mantenimiento también forma parte de la seguridad
En byteStudio Argentina desarrollamos y mantenemos sitios WordPress, verificamos actualizaciones, compatibilidad, backups y funcionamiento general para reducir la exposición frente a fallas conocidas y mantener los proyectos operativos.
Actualizar no significa simplemente presionar un botón: significa conocer el sitio, disponer de recuperación y comprobar que cada cambio quedó correctamente aplicado.
