/ blog 
El 3 de noviembre la agencia de ciberseguridad de Estados Unidos, CISA, añadió a su catálogo de vulnerabilidades explotadas una falla en el núcleo de WordPress, la confirmación oficial de que hay atacantes usándola contra sitios reales. La misma semana se reportó la explotación de un plugin de pagos que fue retirado del directorio oficial hace meses y para el cual no existe corrección. Cerca de la mitad de los sitios del mundo corre sobre WordPress, de modo que estos avisos alcanzan a buena parte de las empresas, directamente o a través del proveedor que les administra el sitio, y las verificaciones que piden son las mismas en ambos casos.
Alcance de la falla en el núcleo de WordPress
La vulnerabilidad del núcleo, identificada como CVE-2026-119977 y calificada con 8.1 sobre 10, afecta a las versiones de WordPress desde la 4.7 hasta la 7.1.3, es decir, a casi una década de instalaciones. El problema está en las carpetas temporales que WordPress crea al actualizarse, dentro de wp-content/upgrade, con nombres predecibles. Un atacante que llegue a esos archivos en el momento justo de una actualización puede conectar el instalador temporal a una base de datos bajo su control y ejecutar código en el servidor sin tener una cuenta en el sitio.
Que el ataque solo funcione durante una actualización reduce menos el riesgo de lo que parece. Como los atacantes no saben cuándo se actualiza cada sitio, bombardean las rutas del instalador de forma continua a la espera de que alguna ventana se abra, y un solo monitoreo registró más de 18.500 solicitudes de este tipo en 21 horas. La corrección llegó el 28 de octubre con WordPress 7.1.4, junto con parches para ramas anteriores. Tener las actualizaciones automáticas activas tampoco cierra el tema por sí solo, porque la falla ocurre justamente durante el proceso de actualización, así que hay que confirmar en el panel que la 7.1.4 quedó instalada por completo.
El riesgo de los plugins retirados del directorio
El segundo aviso involucra un plugin de pagos con criptomonedas para WordPress con una falla calificada con 10 sobre 10, la puntuación máxima de la escala. Un punto de acceso sin verificación de permisos deja que cualquier visitante, sin cuenta en el sitio, ejecute operaciones administrativas, borre archivos del servidor y lea las credenciales de las billeteras, que el plugin guarda en texto plano. Hay intentos de explotación en curso y no existe versión corregida.
Para quien no usa ese plugin, lo relevante del caso está en cómo se llegó a esta situación. El plugin fue retirado del directorio oficial de WordPress el 28 de agosto por un problema de seguridad, y ese retiro no desinstala nada ni notifica a nadie: los sitios que lo tenían siguen ejecutándolo desde entonces, sin actualizaciones, y sus dueños se enteraron del riesgo cuando los ataques ya estaban en curso, dos meses después. Quien tenga este plugin debe eliminarlo hoy y rotar las claves de las billeteras. El mismo mecanismo de abandono silencioso aplica a cualquier otro plugin, y por eso la revisión que sigue incluye verificar cuáles siguen publicados y mantenidos.
Verificaciones recomendadas
En el panel de administración, en la sección de actualizaciones, hay que confirmar que el sitio corre WordPress 7.1.4 o que la rama instalada recibió el parche de seguridad, y en sitios con actualización automática, que el proceso terminó y no quedó a medias. Esta verificación toma un par de minutos. Cuando el sitio lo administra un proveedor de hosting o una agencia, la pregunta por escrito es la misma: qué versión corre el sitio y cuándo se aplicó el parche del 28 de octubre.
El inventario de plugins requiere algo más de tiempo y rinde más. Para cada uno vale revisar la fecha de su última actualización, si sigue publicado en el directorio oficial y si el sitio realmente lo usa. Un plugin desactivado pero instalado sigue siendo código presente en el servidor, de modo que el que no se usa se elimina, y los que llevan más de un año sin cambios o ya no aparecen en el directorio entran a una lista de reemplazo planificado, antes de que el reemplazo tenga que hacerse de emergencia.
Los registros del servidor completan la revisión. Solicitudes a archivos PHP dentro de wp-content/upgrade, cuentas de administrador que nadie reconoce, plugins que nadie instaló y archivos modificados en fechas extrañas son los indicios típicos de un intento o de un compromiso logrado. Mientras se aplica el parche, restringir el acceso público a la carpeta de actualizaciones reduce la exposición, aunque se trata de una medida transitoria, y el firewall funciona como capa adicional, nunca como sustituto de actualizar.
El mantenimiento como control permanente
Un sitio web en producción es software en operación, con las mismas obligaciones de mantenimiento que cualquier otro sistema: un responsable asignado, un inventario de lo que tiene instalado y un ritmo de actualización que no dependa de las emergencias. La mayoría de los sitios comprometidos por fallas como estas llevaban años funcionando sin que nadie los revisara, y los barridos automatizados de los atacantes están diseñados para encontrar exactamente esos sitios entre millones. Donde ese mantenimiento ya existía, los avisos de esta semana se resolvieron con una actualización de rutina; donde no, la tarea pendiente quedó definida en los párrafos anteriores, y conviene hacerla antes de que la defina un incidente.
Fuentes
CISA advierte sobre la vulnerabilidad del núcleo de WordPress explotada en ataques
The Hacker News, ataques al plugin de pagos sin parche disponible
Catálogo de vulnerabilidades explotadas conocidas de CISA
Imágenes generadas con IA
