Atacantes comenzaron a explotar CVE-2026-87902 pocas horas después de publicarse la actualización.
El fallo no requiere autenticación, pero su impacto depende del tema y la configuración del servidor.
Administradores de sitios WordPress enfrentan una carrera contra el tiempo después de que atacantes comenzaran a explotar una vulnerabilidad crítica en el núcleo de la plataforma. El fallo permite manipular el mecanismo utilizado para resolver las plantillas de una página y, bajo determinadas condiciones, ejecutar código en el servidor sin disponer de una cuenta.
La vulnerabilidad, identificada como CVE-2026-87902, fue corregida en WordPress 7.1.2, publicado el 22 de septiembre de 2026. El equipo de seguridad también preparó actualizaciones para numerosas ramas anteriores, mientras investigadores detectaron actividad maliciosa pocas horas después de la publicación de los parches.
La explotación no implica que todos los sitios desactualizados puedan ser comprometidos automáticamente. Para alcanzar la ejecución remota de código deben coincidir condiciones relacionadas con la estructura del tema activo, los archivos PHP disponibles y la configuración del servidor. La ausencia de autenticación y la disponibilidad de información pública sobre el fallo elevan, sin embargo, la urgencia.
El problema está en la resolución de plantillas
WordPress utiliza archivos de plantilla para decidir cómo presentar distintos tipos de páginas. CVE-2026-87902 permite que un atacante manipule este proceso y haga que el sistema intente cargar un archivo PHP local legible ubicado fuera de los directorios del tema activo.
Por sí sola, la inclusión de un archivo local no siempre produce ejecución de código. El resultado depende de qué archivos estén disponibles en el servidor, de sus permisos y de cómo esté configurado el entorno PHP. Cuando existe un archivo adecuado y se cumplen las demás condiciones, el atacante puede convertir la inclusión local en ejecución remota de código.
Un compromiso exitoso podría permitir la modificación del sitio, la instalación de puertas traseras, el acceso a información almacenada, el robo de credenciales o el uso del servidor para atacar a terceros.
Los ataques comenzaron pocas horas después del parche
Patchstack detectó las primeras solicitudes maliciosas el 22 de septiembre, menos de cinco horas después de que WordPress publicara la actualización. La actividad inicial parecía centrada en determinar qué sitios reunían las condiciones necesarias para la explotación.
Posteriormente, los investigadores observaron intentos de utilizar el fallo para escribir archivos PHP en el servidor y ejecutar comandos cuando esos archivos fueran solicitados. La actividad confirma la explotación de la vulnerabilidad, pero no permite calcular cuántos sitios fueron comprometidos con éxito.
La Cyber Security Agency of Singapore emitió el 24 de septiembre una alerta específica en la que confirmó la explotación activa y recomendó actualizar inmediatamente.
No existe, hasta el momento, una atribución pública y confiable. La actividad observada no ha sido vinculada de manera concluyente con un grupo de ransomware, espionaje o ciberdelincuencia determinado.
Una vulnerabilidad de Core con alcance amplio
A diferencia de numerosos incidentes de WordPress que afectan a un complemento o tema específico, CVE-2026-87902 reside en el núcleo de la plataforma. Esto amplía el universo de instalaciones que deben revisar su versión, aunque el impacto final continúe condicionado por cada entorno.
WordPress clasificó el problema como crítico y recomendó actualizar los sitios inmediatamente. Las actualizaciones automáticas en segundo plano comenzaron a desplegarse donde esa función estaba habilitada, pero los administradores deben verificar que el proceso haya terminado correctamente.
Las organizaciones que desactivaron las actualizaciones automáticas, utilizan mecanismos propios de despliegue o mantienen versiones antiguas necesitan intervenir manualmente.
Versiones corregidas
WordPress 7.1.2 contiene la corrección para la rama más reciente. También se publicaron versiones de seguridad para ramas anteriores, entre ellas:
- WordPress 7.1: actualizar a 7.1.2.
- WordPress 7.0: actualizar a 7.0.6.
- WordPress 6.9: actualizar a 6.9.9.
- WordPress 6.8: actualizar a 6.8.10.
- WordPress 6.7: actualizar a 6.7.9.
- WordPress 6.6: actualizar a 6.6.9.
- WordPress 6.5: actualizar a 6.5.12.
- WordPress 6.4: actualizar a 6.4.12.
- WordPress 6.3: actualizar a 6.3.12.
- WordPress 6.2: actualizar a 6.2.13.
- WordPress 6.1: actualizar a 6.1.14.
- WordPress 6.0: actualizar a 6.0.16.
La corrección también fue trasladada a ramas comprendidas entre WordPress 4.7 y 5.9. Las instalaciones 4.6 y anteriores ya no reciben actualizaciones de seguridad y deben migrarse a una versión compatible.
Aunque existan correcciones para ramas antiguas, WordPress recuerda que únicamente la versión más reciente recibe soporte activo completo. Los parches retroactivos deben entenderse como una medida de seguridad, no como una recomendación para mantener indefinidamente software obsoleto.
Por qué el incidente importa más allá de un sitio web
WordPress se utiliza en sitios corporativos, medios de comunicación, comercios electrónicos, organizaciones públicas y plataformas de servicios. Una instalación comprometida puede afectar la reputación de la organización, exponer información de usuarios o convertirse en una plataforma para distribuir malware y campañas de fraude.
Los atacantes también pueden utilizar un sitio legítimo para alojar páginas de phishing, redirigir visitantes, manipular contenido o intentar acceder a otros sistemas mediante credenciales y secretos almacenados en el servidor.
En entornos administrados, una vulnerabilidad de Core puede afectar simultáneamente a numerosos clientes cuando varias instalaciones comparten procesos de actualización, infraestructura o configuraciones similares.
Actualizar no demuestra que el sitio esté limpio
Instalar una versión corregida evita que la vulnerabilidad continúe siendo explotada, pero no elimina archivos, cuentas o modificaciones que un atacante haya creado antes de la actualización.
Los sitios que permanecieron expuestos desde la publicación del parche deben revisar sus registros, buscar archivos PHP nuevos o modificados, comprobar la integridad del núcleo, los temas y los complementos, e investigar cambios inesperados en cuentas administrativas y tareas programadas.
Una copia de seguridad también debe evaluarse antes de utilizarla para una restauración. Recuperar una copia creada después del compromiso puede reintroducir los mismos archivos maliciosos.
Recomendaciones para administradores y organizaciones
- Actualizar inmediatamente WordPress 7.1 a la versión 7.1.2 o instalar la corrección correspondiente a la rama utilizada.
- Confirmar manualmente que las actualizaciones automáticas hayan concluido en todos los sitios administrados.
- Inventariar instalaciones secundarias, entornos de prueba y sitios antiguos que todavía puedan estar accesibles desde internet.
- Preservar los registros antes de limpiar o reinstalar sistemas si existen señales de actividad sospechosa.
- Revisar archivos PHP nuevos o modificados, cuentas administrativas desconocidas y cambios no autorizados en temas o complementos.
- Comparar los archivos de WordPress Core con una distribución oficial y confiable.
- Reinstalar los componentes afectados desde fuentes legítimas cuando no pueda garantizarse su integridad.
- Rotar credenciales, claves de aplicación, secretos y sales de WordPress si se confirma o sospecha un compromiso.
- Verificar que los directorios destinados a archivos subidos no permitan ejecutar PHP cuando la operación del sitio no lo requiera.
- Migrar las versiones 4.6 y anteriores, que ya no reciben actualizaciones de seguridad.
- Mantener copias de seguridad aisladas, recientes y verificadas mediante pruebas de restauración.
- Tratar las reglas de firewall o el parcheo virtual como controles complementarios, no como sustitutos de la actualización de Core.
Qué continúa bajo investigación
Los investigadores todavía no han determinado el número de sitios comprometidos, la distribución geográfica de las víctimas ni todos los objetivos de los atacantes. Tampoco se conoce si la actividad observada corresponde a una sola campaña o a varios operadores que incorporaron rápidamente la vulnerabilidad a sus herramientas.
La evidencia disponible confirma intentos activos de explotación, pero no justifica afirmar que todos los sitios desactualizados fueron comprometidos. Cada organización debe evaluar su exposición según la versión, el tema, la configuración del servidor y la evidencia presente en sus registros.
