Ciberseguridad Gestión de Riesgo 📅 Septiembre 2026 | ⏱️ 8 min de lectura
El 17 de septiembre WordPress corrigió once vulnerabilidades. El 22 de septiembre, cinco días después, publicó otra actualización con una sola corrección, clasificada como crítica. Esta segunda no requiere que nadie haga clic en nada, no necesita cuenta ni contraseña, y afecta a casi una década de versiones. Si su organización no aplicó ninguna de las dos, el problema no son las vulnerabilidades.
Tres preguntas antes de seguir
¿Quién es responsable de actualizar el sitio web de su organización?
¿Cuándo se actualizó por última vez el software que lo hace funcionar?
¿Cómo se enteraría su organización si algo estuviera ocurriendo ahí?
Si las tres tienen respuesta clara y verificable, estas actualizaciones probablemente ya están aplicadas. Si alguna no la tiene, conviene seguir leyendo.
Lo que ocurrió en cinco días
WordPress opera el 40,3% de los sitios web del mundo, según datos de W3Techs.
17 de septiembre
Versión 7.1.1
Once correcciones de seguridad. El aviso oficial recomienda actualizar de inmediato.
22 de septiembre
Versión 7.1.2
Una sola corrección, clasificada como severidad crítica. Misma recomendación: actualizar de inmediato.
Dos actualizaciones de seguridad en cinco días no es habitual. Y la segunda es considerablemente más seria que la primera.
Por qué la segunda es distinta
La primera actualización corrigió problemas que, en general, requerían alguna condición. Que un administrador abriera una página determinada. Que alguien hiciera clic en un enlace. Que existiera una cuenta con ciertos permisos.
La segunda no requiere ninguna condición de ese tipo.
El aviso oficial de WordPress lo describe así: un atacante no autenticado puede, bajo ciertas condiciones, hacer que el sistema cargue un archivo del servidor que no debería cargar. Si se cumplen determinadas condiciones del servidor y del diseño del sitio, eso puede derivar en ejecución de código.
No autenticado significa que no hace falta cuenta, contraseña ni acceso previo de ningún tipo.
Patchstack, la organización que coordina la divulgación de vulnerabilidades en el ecosistema WordPress, la califica como lo más serio que WordPress ha corregido en bastante tiempo, con un puntaje de severidad de 9,2 sobre 10.
El alcance: casi una década de versiones
La vulnerabilidad afecta a todas las versiones de WordPress desde la 4.7 hasta la 7.1.1 inclusive.
La versión 4.7 se publicó a fines de 2016. En términos prácticos, esto significa que cualquier sitio WordPress que no se haya actualizado en los últimos días está afectado, independientemente de qué tan antigua sea su instalación.
WordPress publicó correcciones para todas las ramas que aún reciben soporte de seguridad, hasta la 4.7. Un sitio antiguo puede recibir la corrección sin cambiar de versión mayor.
Pero el aviso oficial incluye una advertencia que conviene leer literalmente: solo la versión más reciente de WordPress recibe soporte activo.
El detalle que explica cómo ocurren estas cosas
Hay un elemento en el análisis técnico que merece atención, porque ilustra algo sobre la naturaleza de estos problemas.
WordPress tiene una función propia diseñada específicamente para verificar que una ruta de archivo sea segura. Existe hace años y se usa en múltiples lugares del sistema.
En el código donde estaba la vulnerabilidad, esa verificación sí se aplicaba a uno de los caminos posibles. Y no se aplicaba al camino que resultó vulnerable.
La formulación de Patchstack es precisa: la protección existía tres líneas más arriba del lugar donde faltaba.
No fue un descuido de diseño ni una falla conceptual. Fue una verificación que quedó fuera en un caso particular, y permaneció así durante casi diez años.
Una decisión del equipo de seguridad que vale la pena notar
WordPress publicó dos cambios en esta corrección, no uno.
El primero aplica la verificación que faltaba. Habría sido suficiente para resolver el problema reportado.
El segundo agrega una verificación general que ahora deben pasar todas las rutas de plantilla, sin importar por qué camino del código se hayan generado.
La lectura que hace Patchstack de esa decisión es relevante para cualquier organización: el equipo de seguridad trató el asunto como una categoría de problema, no como un error puntual. Y eso sugiere que no tenían certeza de que el camino reportado fuera el único.
Qué tan común es la condición que activa el peor escenario
La ejecución de código requiere dos condiciones adicionales, y aquí es donde muchas organizaciones asumen incorrectamente que no les aplica.
La primera tiene que ver con el diseño del sitio. La segunda con la configuración del servidor.
Sobre esta última, Patchstack es explícito: esa configuración viene activada por defecto en las imágenes oficiales de PHP para contenedores y en entornos cPanel con versiones de PHP anteriores a la 8.5.
Su conclusión es directa: describir esto como una configuración inusual subestima cuán común es. Y agrega una recomendación que cualquier organización debería adoptar como criterio: tratarlo como crítico, salvo que se haya verificado el propio entorno y se sepa lo contrario.
cPanel es el panel de administración más extendido entre los proveedores de hosting compartido en Chile.
Qué significa un sitio comprometido
Conviene desarmar una idea instalada: que el sitio web es un activo de marketing.
Un sitio comprometido no genera un problema de imagen. Genera un servidor que responde a otra persona.
Lo que un tercero puede hacer con ese acceso
- →Enviar correo desde el dominio de la organización
- →Alojar contenido fraudulento bajo su marca
- →Redirigir a sus visitantes hacia estafas
- →Mantenerse disponible para ser revendido a quien quiera utilizarlo después
Para organizaciones en Chile hay una consideración adicional. Si ese sitio procesa datos de clientes, proveedores o postulantes, la Ley 21.719 lo alcanza. Un compromiso de ese tipo deja de ser un asunto técnico y pasa a ser un incidente con obligaciones de notificación.
El factor tiempo
5 horas
Tiempo mediano entre que una vulnerabilidad de WordPress se hace pública y comienza a explotarse de forma masiva
Patchstack, State of WordPress Security In 2026
Esta vulnerabilidad se publicó el 22 de septiembre, con su mecanismo documentado en detalle y su identificador asignado el mismo día.
Qué corresponde hacer
Actualizar a la versión 7.1.2
Es la versión vigente. Actualizar a la 7.1.1 no resuelve esta vulnerabilidad, porque la 7.1.1 está entre las versiones afectadas.
Verificar que efectivamente se aplicó
Tener configurada la actualización automática no garantiza que se haya ejecutado. Corresponde confirmar el número de versión en el panel de administración.
Si el sitio opera sobre una versión antigua, verificar la corrección específica
WordPress publicó versiones corregidas para todas las ramas que aún reciben soporte, hasta la 4.7.
Si no es posible actualizar de inmediato, consultar dos cosas a quien administra el sitio
Patchstack señala dos verificaciones que no corrigen el problema, pero indican qué tan cerca está la organización del peor escenario: si el tema activo del sitio tiene cierta estructura de carpetas, y si el servidor tiene activada una configuración específica de PHP.
Cualquier proveedor de hosting o desarrollador puede responder ambas en minutos. Si no puede, esa es información relevante por sí misma.
Para entender por qué la ausencia de incidentes reportados no equivale a seguridad, revisa nuestro análisis sobre capacidad de detección y gobernanza. Y para las obligaciones que la Ley 21.719 impone en caso de un incidente con datos personales, revisa la guía práctica de cumplimiento.
Dos actualizaciones de seguridad en cinco días, ambas con la misma recomendación de actualizar de inmediato. La segunda afecta a casi diez años de versiones y no requiere que nadie en su organización haga nada para ser explotada. El parche existe, es gratuito y aplicarlo toma minutos. Lo que determina el resultado no es la disponibilidad de la corrección, sino si alguien tiene asignada la responsabilidad de aplicarla. En una cantidad considerable de empresas esa responsabilidad no está en ninguna parte: el sitio lo desarrolló una agencia hace algunos años, funciona sin problemas, nadie lo revisa.
¿Sabe cuándo se actualizó por última vez el sitio de su organización?
Fuentes: WordPress.org, aviso oficial de la versión 7.1.2, publicado por John Blackbourn el 22 de septiembre de 2026 · WordPress.org, aviso oficial de la versión 7.1.1, publicado por Aaron Jorbin el 17 de septiembre de 2026 · Patchstack, análisis técnico de CVE-2026-87902, publicado el 22 de septiembre de 2026 · Patchstack, State of WordPress Security In 2026 · W3Techs, estadísticas de uso de sistemas de gestión de contenido, consultado en septiembre de 2026.
¿Su organización sabe en qué estado está su sitio web?
En CSITI revisamos el estado de actualización, la configuración de seguridad y los puntos de exposición de sitios corporativos. El resultado es un informe con lo que hay que corregir, ordenado por prioridad, y quién debería hacerse cargo de cada punto.
