CVE-2026-23550: explotación activa en Modular DS para WordPress permite escalar a admin sin autenticación

Esta semana ha saltado una alerta seria para cualquiera que gestione sitios WordPress con el plugin Modular DS: una vulnerabilidad de máxima severidad (CVE-2026-23550, CVSS 10.0) está siendo explotada activamente para conseguir acceso de administrador sin autenticación. El incidente lo ha documentado Patchstack y afecta a todas las versiones hasta la 2.5.1 incluida, con corrección disponible en la 2.5.2.

Si administras varios WordPress (agencia, mantenimiento, hosting gestionado), este es el típico caso en el que no basta con “actualizar cuando puedas”: el vector es directo, la recompensa para el atacante es total (admin) y ya hay tráfico malicioso en la naturaleza.

Qué se ha descubierto exactamente

El problema se describe como una escalada de privilegios sin autenticación (unauthenticated privilege escalation): un atacante puede activar un flujo de login y terminar con una sesión de administrador, o bien utilizar rutas internas sensibles para extraer información y preparar una intrusión más profunda.

Según los detalles publicados, el fallo está en la capa de enrutado del plugin (routing). Modular DS expone endpoints bajo el prefijo /api/modular-connector/ y, en teoría, algunas rutas deberían estar protegidas detrás de una barrera de autenticación (middleware). El fallo es que esa barrera se puede saltar en determinadas condiciones.

Cómo se salta la autenticación: “direct request” y parámetros permisivos

Patchstack explica que la protección se puede bypassear cuando está habilitado un modo llamado “direct request”. Basta con enviar una petición que incluya un parámetro origin=mo y un type con cualquier valor para que el plugin trate la llamada como una “petición directa” de Modular.

El matiz importante: el bypass pasa a ser crítico cuando el sitio ya está conectado a Modular, es decir, cuando existen tokens (presentes/renovables). En ese escenario, el sistema permite pasar el middleware sin que exista un vínculo criptográfico real entre la petición entrante y el servicio legítimo.

Rutas expuestas y el impacto real en un WordPress

Con el bypass, quedan expuestas varias rutas (Patchstack menciona, entre otras) /login/, /server-information/, /manager/ y /backup/. El rango de acciones posibles va desde login remoto hasta acceso a información sensible del sistema o de usuarios.

El escenario más grave es el endpoint de login: un atacante no autenticado puede abusar de la ruta /api/modular-connector/login/{modular_request} para conseguir acceso de administrador, lo que en la práctica equivale a compromiso completo del sitio: cambios maliciosos, instalación de malware (plugins/archivos), modificación de redirecciones o inyección de contenido para estafas.

Señales de explotación observadas: endpoints y patrones

Patchstack indica que los ataques se detectaron por primera vez el 13 de enero de 2026 alrededor de las 02:00 UTC, con llamadas HTTP GET al endpoint /api/modular-connector/login/ y, a continuación, intentos de crear un usuario administrador.

También se han compartido IPs de origen asociadas a la actividad:

• 45.11.89[.]19 (referencia en VirusTotal: https://www.virustotal.com/gui/ip-address/45.11.89.19)
• 185.196.0[.]11 (referencia en VirusTotal: https://www.virustotal.com/gui/ip-address/185.196.0.11)

Versiones afectadas y parche disponible

El alcance comunicado es claro: afecta a todas las versiones de Modular DS hasta la 2.5.1 incluida. La corrección está publicada en Modular Connector 2.5.2. Nota práctica: en incidentes con explotación activa, actualizar el plugin es el primer paso, pero no el último (si ya entraron, la actualización no “desinfecta” el sitio).

Detalles del release de seguridad: https://help.modulards.com/en/article/modular-ds-security-release-modular-connector-252-dm3mv0/

Checklist de respuesta rápida si usas Modular DS

Además de actualizar, Modular DS recomienda revisar indicios de compromiso (usuarios admin inesperados, peticiones sospechosas de scanners) y ejecutar medidas de contención. En un WordPress típico, el orden razonable sería:

1. Actualizar Modular DS a la versión parcheada (2.5.2) cuanto antes.
2. Auditar usuarios administradores: buscar cuentas nuevas o cambios recientes de email/rol.
3. Regenerar las WordPress salts para invalidar sesiones existentes (corta cookies/tokens activos).
4. Regenerar credenciales OAuth asociadas a la integración (si aplica en tu configuración).
5. Escanear el sitio en busca de plugins/archivos/código malicioso (especial atención a wp-content/plugins/, wp-content/mu-plugins/ y tareas programadas).

Una lección de diseño: confiar en rutas “internas” expuestas a Internet

Más allá del incidente puntual, esta vulnerabilidad es un recordatorio incómodo para quienes desarrollamos plugins o APIs: cuando expones endpoints públicos, cualquier “camino interno” que dependa de flags o parámetros para considerarse de confianza termina siendo un punto débil. Si la verificación se basa en “el sitio está conectado” en lugar de validar criptográficamente la petición, estás asumiendo una confianza implícita que Internet no respeta.

En este caso, los mantenedores del plugin han indicado que el fallo estaba en una capa de routing personalizada que extendía el matching de rutas de Laravel, y que esa lógica era demasiado permisiva, permitiendo que peticiones construidas a mano alcanzasen endpoints protegidos sin validar correctamente la autenticación.