Post-mortem del incidente de seguridad de Modular Connector (enero 2026)

Tras el incidente de seguridad que afectó al plugin de Modular Connector hace unas semanas, y ahora que todo está más controlado y tenemos más información, queremos compartir más detalles sobre lo que sucedió, cómo lo gestionamos y qué estamos haciendo para evitar que vuelva a repetirse.

El 14 de enero de 2026 recibimos un aviso por parte de Patchstack, gracias a Teemu Saarentaus, sobre una vulnerabilidad crítica de seguridad en el plugin de Modular DS (Modular Connector).

Esta vulnerabilidad podía permitir que un atacante no autorizado obtuviera acceso de administrador en webs de WordPress. Publicamos una corrección en 82 minutos y, desde ese momento, empezamos a forzar la actualización en todas las webs conectadas a Modular DS.

El 16 de enero, como parte de la investigación y monitorización tras el primer incidente, detectamos un bypass relacionado derivado del mismo fallo en la lógica de enrutamiento. Identificamos el problema y su origen con mayor rapidez, implementamos una solución más robusta y sacamos la versión 2.6.0, con el 97% de las webs conectadas actualizadas antes de que se publicara el CVE.

La seguridad es una prioridad en Modular DS y seguimos 100% comprometidos con la protección de nuestros usuarios. La vulnerabilidad sucedió por un fallo en la lógica de enrutamiento del plugin que, combinado con otros factores, abrió una vía para saltarse la autenticación.

La buena noticia es que nuestra investigación confirma que no se comprometieron datos de la plataforma de Modular DS, y que la gran mayoría de webs quedaron protegidas en cuestión de horas tras publicar los parches.

Resumen técnico

El plugin Modular Connector implementa un sistema de rutas personalizado basado en Laravel. Esto es necesario porque muchas instalaciones de WordPress bloquean el JSON API por defecto (normalmente por plugins de seguridad como Wordfence o iThemes Security) y necesitábamos una forma fiable de que nuestra plataforma pudiera comunicarse con el plugin.

Para ejecutar acciones en las webs conectadas, el plugin utiliza un sistema seguro: Modular DS genera un identificador de petición único (válido solo durante unos minutos) que el plugin intercambia por instrucciones únicamente después de validar su token de acceso OAuth2. Este sistema sigue siendo seguro y no se vio comprometido.

La vulnerabilidad estaba en nuestra capa de enrutamiento, que contaba con una arquitectura de rutas doble:

• Enrutamiento dual con fallback inseguro: nuestro router personalizado estaba por encima del router nativo de Laravel. Cuando nuestro router no conseguía resolver una petición, se producía un fallback que devolvía la ruta original que Laravel había emparejado, incluyendo endpoints sensibles como /login/, que deberían haber estado protegidos.
• Flujo de enrutamiento expuesto: el método isDirectRequest() decide cuándo usar el sistema de rutas personalizado en función de ciertos parámetros de URL (origin=mo y type=…). Un atacante podía utilizar esos parámetros para entrar en ese flujo y provocar el fallback inseguro.
• Auto-login: el endpoint de login, cuando se accedía sin especificar un usuario, autenticaba automáticamente como el primer administrador disponible.

Al combinar estos factores, un atacante podía crear una URL que activase el enrutamiento personalizado, no coincidiera con ninguna ruta válida, recurriera a la ruta /login/ de Laravel y obtuviera acceso como administrador.

El parche en la versión 2.5.2 eliminaba la arquitectura doble de rutas, aplicaba un emparejamiento estricto de rutas con una respuesta 404 por defecto y añadía verificación adicional en la identificación de peticiones.

El 16 de enero, durante la investigación y monitorización posteriores, identificamos un bypass relacionado (CVE-2026-23800) derivado del mismo fallo en la lógica de enrutamiento. No era una vulnerabilidad nueva o diferente, sino una continuación del problema original: una vía de ejecución distinta dentro del mismo sistema que podía otorgar acceso con nivel de administrador a rutas de la REST API de WordPress.

Dado que detectamos este bypass pronto y vimos que no estaba siendo explotado de forma generalizada en ese momento, tomamos la decisión de implementar una solución más sólida.

La versión 2.6.0 incluye autenticación JWT (JSON Web Token), un método de seguridad en el que cada petición entre nuestra plataforma y el plugin se firma con un token criptográfico extremadamente difícil de falsificar.

Digamos que es como una firma digital que solo Modular DS y tu web pueden verificar, lo que hace mucho más difícil que alguien pueda suplantar nuestra plataforma. Además, hemos rediseñado el sistema de enrutamiento para eliminar la causa raíz que hizo posibles ambos bypasses.

Para un análisis técnico más detallado, puedes echar un vistazo a este artículo de Patchstack.

Impacto

Lo que debes saber

*Importante: CVE-2026-23800 no fue una vulnerabilidad nueva o diferente. Fue una continuación del mismo fallo en la lógica de enrutamiento que causó la vulnerabilidad CVE-2026-23550, explotando una ruta distinta.

¿Se vieron afectadas tus webs?

Si tu web tenía instalada cualquier versión de Modular Connector anterior a la 2.6.0, podía ser potencialmente vulnerable.

Durante la investigación del primer incidente, identificamos 1.384 sitios que mostraban indicadores de posible exposición. El segundo bypass lo detectamos rápidamente y encontramos 154 webs potencialmente en riesgo antes de que publicáramos la corrección de seguridad.

Además de avisar a nuestros usuarios para que actualizasen lo antes posible, contactamos con los propietarios de esos sitios, dándoles más información específica para cada caso.

Qué fue bien

A pesar de la gravedad de la situación, hubo varias cosas que funcionaron bien:

• Corrección rápida. Publicamos un parche en 82 minutos desde que recibimos el aviso.
• Actualizaciones masivas en poco tiempo. Tras publicar la versión 2.5.2, nuestro sistema lanzó actualizaciones en todas las webs conectadas a Modular DS y conseguimos proteger el 97,64% en 35 horas.
• Comunicación proactiva. Trabajamos en un aviso de seguridad y notificamos a nuestros usuarios lo antes posible a través de la plataforma, email y seguimiento directo a las cuentas con webs potencialmente afectadas.
• Investigación a fondo. Dedicamos 14 horas a revisar datos y actividad de la plataforma para confirmar que no se comprometieron datos.
• Mejoras inmediatas. En menos de 36 horas, publicamos una nueva funcionalidad para ayudar a detectar patrones típicos de ataque, como la creación de nuevos usuarios administradores no autorizados o la eliminación de usuarios legítimos para tomar el control de una web.
• Divulgación responsable. El equipo de group.one descubrió y reportó el problema de forma responsable, y Patchstack coordinó la publicación del CVE y validó nuestra corrección.
• Mejor respuesta ante el bypass relacionado. Cuando lo detectamos dos días después, los procesos de monitorización que pusimos en marcha tras el primer incidente nos permitieron identificar el problema y lo que lo estaba causando en 30 minutos. En lugar de sacar un parche rápido, invertimos el tiempo necesario para publicar una solución más robusta con autenticación JWT. Tras la publicación de la versión 2.6.0, la mayoría de las webs conectadas se actualizaron en aproximadamente una hora, una mejora significativa respecto al primer incidente.

Qué hemos aprendido

Aunque el equipo fue eficaz y reaccionó rápidamente para corregir la vulnerabilidad, en las primeras horas nos dimos cuenta de mejoras que podemos implementar para reforzar nuestra respuesta ante este tipo de incidentes, sobre todo a nivel de coordinación y comunicación a gran escala.

Estamos trabajando en un plan de actuación más organizado, en el que esté más claro quién lidera y valida decisiones clave y en qué orden debemos preparar acciones y comunicaciones. Esto incluye playbooks de mensajes y protocolos, además de guías con medidas de mitigación ante situaciones urgentes para evitar disrupciones y trabajo innecesario a nuestros usuarios.

También fue la primera vez que nuestro sistema tuvo que actualizar todas las webs conectadas al mismo tiempo. Aunque nuestra arquitectura está bien preparada, el pico de tráfico dejó ver procesos de API con consultas de base de datos muy pesadas que consumieron más memoria de lo esperado. Como consecuencia, la plataforma fue más lenta o no respondió con normalidad temporalmente.

Por otra parte, durante el incidente, nuestro equipo técnico decidió priorizar el procesamiento de actualizaciones del plugin frente a la disponibilidad completa de la plataforma. Fue la decisión correcta para proteger todas las webs lo antes posible, pero también confirmó que podemos mejorar el rendimiento ante acciones urgentes de seguridad sin impactar la experiencia de usuario.

La respuesta técnica fue rápida. Ahora estamos haciendo que nuestros procesos e infraestructura estén a esa misma altura. Que sean todavía más rápidos, sólidos y fiables.

Hemos compartido más detalles de todas las mejoras que ya estamos implementando en este apartado más abajo.

Nuestra respuesta

Las primeras horas

Nada más recibir el aviso (14 de enero a las 08:04 UTC), empezamos a investigar. Este fue el timeline de ese día y los posteriores en líneas generales.

14 de enero de 2026

• 08:30 UTC: Patchstack confirma la vulnerabilidad CVE-2026-23550 y publicamos el primer aviso para notificar a usuarios.
• 09:26 UTC: Publicamos la versión 2.5.2 del plugin en WordPress.org (82 minutos después del aviso).
• 10:28 UTC: Patchstack confirma que el fix funciona. Empezamos a forzar actualizaciones en todas las webs conectadas a Modular DS.
• 10:28 UTC: Comenzamos un análisis en profundidad para comprobar que no había filtración de datos en la plataforma.
• 12:30 UTC: Publicamos una notificación en la app con pasos y recomendaciones para todos los usuarios.
• 14:30 UTC: Enviamos un email explicando lo sucedido y las acciones recomendadas.

15 de enero de 2026

• 00:13 UTC: Tras casi 14 horas de análisis, no encontramos evidencias de ninguna filtración de datos en la plataforma.
• 06:38 UTC: El 95% de las webs de Modular DS ya están actualizadas a la versión corregida del plugin.
• 06:38 – 10:13 UTC: Empezamos una retrospectiva completa para entender lo ocurrido en detalle.
• 10:13 – 20:11 UTC: Auditamos la seguridad de la plataforma en todos los puntos de integración e identificamos sitios potencialmente afectados. También seguimos dando soporte a usuarios y respondiendo dudas.
• 20:11 UTC: Enviamos emails personalizados a los usuarios con webs potencialmente afectadas (1.384 mostraron señales de exposición y el 97,64% ya estaba parcheado en ese momento).
• 20:21 UTC: Publicamos una nueva funcionalidad de seguridad para recibir alertas cuando se añaden o eliminan usuarios administradores

16 de enero de 2026 – Se detecta y resuelve el segundo bypass

• 07:00 – 13:00 UTC: Seguimos revisando el código del plugin para buscar posibles casos límite, refinamos reglas de monitorización y empezamos a evaluar la posibilidad de implementar autenticación JWT para la comunicación entre la plataforma y el plugin.
• 13:00 – 14:05 UTC: Como parte de la monitorización que reforzamos tras el primer incidente, detectamos un comportamiento inusual en un pequeño número de webs y empezamos conversaciones con Patchstack. Identificamos un bypass relacionado (CVE-2026-23800) con el mismo fallo en la lógica de enrutamiento.
• 14:05 UTC: Identificamos el origen del problema. En lugar de publicar un parche intermedio, decidimos implementar la autenticación JWT y rediseñar el sistema de enrutamiento para cortar el problema desde la raíz.
• 18:50 UTC: Probamos la versión 2.6.0 en staging y Patchstack la valida.
• 19:22 UTC: Publicamos la nueva versión y empezamos a actualizar todas las webs conectadas a Modular DS.
• 20:14 UTC: Se publica oficialmente la vulnerabilidad CVE-2026-23800. En ese momento, el 97% de los sitios conectados ya están en la versión 2.6.0.
• 20:25 UTC: Enviamos un email a nuestros usuarios con más información y les pedimos que comprueben que el plugin está actualizado a la última versión.
• 23:34 UTC: Tras comprobar el estado de las actualizaciones, revisar los dashboards de monitorización y confirmar que no hay ninguna otra actividad sospechosa, cerramos el día.

17-19 de enero de 2026

• Durante el fin de semana, todo el equipo estuvo monitorizando las webs conectadas a la plataforma y pendiente de cualquier actividad en ella para asegurarnos de que no surgía ningún otro problema.

En dos días, mejoramos de forma significativa nuestra respuesta en todos los frentes. El trabajo realizado en los días previos (revisando puntos débiles de infraestructura, planificando la implementación de JWT y reforzando la monitorización) nos permitió detectar antes el problema, tomar mejores decisiones bajo presión y trabajar en una mejor solución con mayor rapidez.

Nuestra investigación

Tan pronto como nos informaron de la vulnerabilidad, el equipo técnico empezó un análisis de logs en la plataforma. Una de nuestras preocupaciones era la posibilidad de que se hubieran comprometido datos o de que se hubiera producido una enumeración de sitios, ya que el ataque empezó de forma simultánea en múltiples webs y no habíamos recibido avisos similares en días anteriores.

Nuestra hipótesis inicial fue que el atacante había estado identificando webs vulnerables durante un tiempo y esperó el momento adecuado para llevar a cabo el ataque.

Analizamos logs para buscar patrones sospechosos y revisamos la base de datos para detectar actividad extraña. Tras casi 14 horas de análisis, no encontramos evidencias de filtración de datos ni de compromiso de los sistemas internos de Modular DS.

¿Cómo encontró el atacante los sitios?

Actualmente creemos que el atacante utilizó plataformas de escaneo como Shodan o Censys para identificar webs de WordPress que tenían instalado nuestro plugin. Estas plataformas rastrean internet de forma continua e indexan información sobre servidores, puertos abiertos y tecnologías, lo que permite localizar firmas de software a gran escala.

Las webs de WordPress suelen ser relativamente fáciles de identificar por patrones en el HTML, rutas habituales y metadatos. Además, muchos plugins incluyen firmas identificables en su código, lo que hace todavía más fácil detectarlos. Es decir, un atacante con conocimiento de una vulnerabilidad puede reunir una lista de objetivos sin necesidad de interactuar con nuestra plataforma.

Esto no significa que WordPress sea inseguro. WordPress es el CMS detrás del 40% de todas las webs del mundo por una razón. El core es seguro y se audita de forma constante. Pero como cualquier ecosistema con plugins y temas, pueden aparecer vulnerabilidades en código de terceros, incluido el nuestro.

¿La conclusión? Mantén siempre todo actualizado. Cuando un plugin tiene una vulnerabilidad, como en este caso, se puede explotar a gran escala con scripts automatizados. Pero si las actualizaciones se aplican rápido, el tiempo de exposición es mínimo.

Y por eso existe Modular DS: para ayudarte a mantener tus webs al día y protegidas sin tener que revisar una por una.

La seguridad es un reto de todo el ecosistema, no exclusivo de Modular DS, pero refuerza por qué la rapidez de respuesta y de las actualizaciones son tan importantes cuando aparecen vulnerabilidades.

Qué deberías hacer

Si aún no lo has hecho, asegúrate de que tus webs de WordPress tengan instalada la versión 2.6.0 o superior del plugin de Modular Connector y revisa estos posibles indicadores de compromiso.

Si detectas algo raro, como peticiones sospechosas, cuentas admin inesperadas o cambios desconocidos, por favor completa los pasos adicionales que explicamos en nuestro artículo de soporte.

Nueva funcionalidad de seguridad: Alertas de cambios en administradores

Como resultado de este incidente, hemos trabajado en una nueva funcionalidad de Modular DS que te avisa cuando se añade o se elimina un usuario administrador en cualquiera de tus webs conectadas.

Este es justamente uno de los cambios que intentaron hacer durante un ataque como este. Con estas alertas activadas, podrás enterarte al momento si se detectan cambios en administradores.

La buena noticia: si ya tenías configuradas notificaciones con la opción “Nueva vulnerabilidad detectada”, esta funcionalidad ya está activa por defecto.

Para activarlo manualmente:

1. Entra en tu panel de Modular DS
2. Ve a Notificaciones
3. Crea una nueva configuración de notificación y/o actívala en la sección “Seguridad”:
   • “Nuevo usuario administrador añadido”
   • “Usuario administrador eliminado”

Qué estamos haciendo para evitar que un incidente así vuelva a pasar

Medidas ya completadas:

• Hemos publicado las versiones corregidas 2.5.2 y 2.6.0.
• Hemos eliminado la lógica vulnerable de enrutamiento y rediseñado el sistema de rutas.
• Hemos implementado autenticación JWT para toda la comunicación entre la plataforma de Modular DS y el plugin.
• Hemos añadido notificaciones de detección de cambios de usuarios administradores a la herramienta.
• Hemos realizado una auditoría de seguridad completa de la plataforma sin encontrar evidencias de filtración de datos.
• Hemos auditado los procesos de comunicación con plataformas externas (Stripe, Vonage y otras), mejorando la seguridad en integraciones.
• Hemos activado nuevos módulos de monitorización de seguridad en Datadog para detectar comportamientos inusuales y permitir acciones de respuesta inmediata.
• Hemos hecho mejoras adicionales de seguridad a nivel de API.

Mejoras técnicas en progreso:

• Completar una auditoría de seguridad de las funcionalidades del plugin y la plataforma.
• Mejorar las herramientas de análisis estático de código para detectar patrones de vulnerabilidad antes de llegar a producción.
• Rediseñar cómo detectamos actualizaciones de plugins premium, que fue el origen del fallo en el sistema de enrutamiento que permitió ambos bypasses. Estamos trabajando en un nuevo enfoque desde cero.
• Optimizar procesos internos para escenarios de alto tráfico: reestructurar funciones como el sistema de webhooks para mejorar el rendimiento de base de datos durante picos.
• Aplicar sistemas adicionales de detección para identificar patrones de actividad inusual o sospechosa en webs conectadas.

Mejoras de procesos en progreso:

• Mejorar el plan de respuesta ante incidentes de seguridad con procesos, roles y acciones de comunicación mejor documentados.
• Publicar una página de status pública para mayor visibilidad en tiempo real del estado de la plataforma y de cualquier incidente.
• Practicar nuestros procesos de respuesta ante incidentes para que todo el equipo sepa exactamente qué hacer cuando surja un problema.
• Preparar plantillas de post-mortem para documentar futuros incidentes de forma más eficiente.

Wall of love

Estos últimos días han sido muy intensos para todo el equipo.

Cuando enviamos el aviso de seguridad, nos preparamos para las críticas. Y, sin embargo, lo que llegó fue una oleada enorme de apoyo que nos ha emocionado.

Muchos entrasteis a Modular DS preocupados y os encontrasteis con que el plugin ya estaba actualizado. Algunos nos escribisteis para preguntar cómo podíais ayudar. Otros nos mandasteis un “gracias por la rapidez y transparencia” o un “confiamos en vosotros”.

Mensajes así nos recuerdan por qué hacemos lo que hacemos. Gestionar múltiples webs de WordPress ya es suficientemente estresante como para tener que vivir este tipo de incidentes de seguridad. Y saber que confiáis en Modular DS para gestionarlas nos hace estar aún más comprometidos por ganarnos esa confianza cada día.

A nuestros usuarios: gracias por vuestra paciencia, comprensión y apoyo. Sois la razón por la que existe Modular DS y no nos tomamos esa responsabilidad a la ligera. Sabemos que en las primeras horas no hicimos todo perfecto. Pero estamos aquí, os escuchamos y os vamos a seguir ayudando en todo lo que podamos.

A Teemu Saarentaus (group.one): gracias por descubrir y reportar esta vulnerabilidad de forma responsable.

A Patchstack: gracias por coordinar la publicación del CVE y verificar nuestra corrección.

A Carles Javierre: gracias por el apoyo y por las mejoras de seguridad aplicadas a nivel de nuestra infraestructura.

Y gracias, de corazón, a todo el equipo por todo el esfuerzo y compromiso durante unos días especialmente difíciles.

Somos un equipo pequeño, pero momentos como este nos recuerdan que formamos parte de algo mucho más grande.

Gracias por formar parte de esta comunidad.

Recursos relacionados

• Artículo de soporte de Modular DS
• Artículo de seguridad de Patchstack
• CVE-2026-23550
• CVE-2026-23800

La transparencia es importante para nosotros y seguiremos compartiendo avances a medida que vayamos implementando más mejoras de seguridad.