Para: usuarios de mStudio de mittwald (principalmente agencias web alemanas) y operadores que ejecutan un servidor MCP que conecta asistentes de IA con su propio servicio. Este artículo se basa en la entrada oficial del blog de mittwald y en sus preguntas frecuentes. No trata pasos de ataque.
En desarrollo: este artículo se actualizará a medida que la organización publique más información
- A quién afecta
usuarios de mStudio de mittwald (principalmente agencias web alemanas) y operadores que ejecutan un servidor MCP que conecta asistentes de IA con su propio servicio.
- Confirmado hasta ahoraVer la tabla ↓
- Punto de entrada
- Proyectos de clientes comprometidos
- Periodo tratado como comprometido
4 más
- Descubrimiento y apagado
- Información leída
- Situación a 6 de noviembre
- Publicación de datos
Señalado como posiblemente afectado
- Uso de herramientas de IA
- Aún sin confirmar
- Si se accedió a archivos, bases de datos o buzones de clientes (la empresa dice que su revisión continúa)
- Los detalles y la ubicación del fallo (código de la empresa o una biblioteca)
- El informe detallado de la empresa (previsto para la semana siguiente)
2 más
- Si volverá el servidor MCP
- Si realmente se usaron herramientas de IA (la empresa lo llama una sospecha)
- Qué hacer ahoraVer los pasos ↓
- Compruebe si está afectado: ¿usó el servidor MCP y recibió un correo de la empresa?
- Si está afectado: cambie la contraseña y active la autenticación en dos pasos
- Revise las claves de API, los tokens de proyecto y las claves SSH
3 más
- Rote las credenciales de servicios externos e informe a las personas implicadas
- Pregunte a la empresa por los sitios web bloqueados y las copias de seguridad
- Operadores de servidores MCP: revisen su propia configuración
- Dónde verificarlo (fuente)Todas las fuentes ↓
- mittwald, «Sicherheitsvorfall am MCP-Server» (blog oficial, en alemán; cronología hasta el 7 de noviembre)
- Última comprobación
- A 10 de noviembre de 2026
Próximos avisos y qué comprobamos
La cronología del blog de la empresa llega hasta el 7 de noviembre de 2026. La empresa dice que publicará un relato detallado la semana siguiente, cuando su análisis y la recuperación estén totalmente completos, y que hasta entonces compartirá información a través de su página de estado y por correo. Cuando lo comprobamos el 10 de noviembre de 2026, todavía no encontramos ese informe.
Qué deben hacer hoy los usuarios de mittwald y los operadores de MCP
Compruebe si está afectado: ¿usó el servidor MCP y recibió un correo de la empresa?
Según las preguntas frecuentes de mittwald, los afectados son los clientes que usaron el servidor MCP, y reciben un correo personal. Si nunca configuró el servidor MCP y no recibió ningún correo, la opinión actual de la empresa es que no está afectado. Se sigue recomendando la autenticación en dos pasos.
La empresa aconseja tratar la cuenta como potencialmente comprometida si usó el servidor MCP el 27 de octubre de 2026 o después, el día en que el atacante explotó realmente el fallo.
Si está afectado: cambie la contraseña y active la autenticación en dos pasos
Siguiendo la guía de la empresa, cambie su contraseña de mStudio y active la autenticación en dos pasos. Ahora que mStudio vuelve a estar disponible, también puede configurar una passkey. Sobre las passkeys, véase Qué es una passkey; sobre lo básico de la autenticación multifactor, Primeros pasos con la autenticación multifactor.
Revise las claves de API, los tokens de proyecto y las claves SSH
Esto sigue la guía de la empresa.
- Revise su lista de claves de API, tokens de proyecto y claves SSH, y elimine lo que no reconozca
- En particular, busque usuarios SSH que no creó usted mismo
- La empresa ha revocado claves de API por precaución
Cómo tratar las claves SSH se explica en Mínimo privilegio para las claves SSH.
Rote las credenciales de servicios externos e informe a las personas implicadas
La empresa aconseja renovar las credenciales de servicios de terceros como bases de datos, correo y API externas. Informe también a las personas que usan sus proyectos (sus clientes y su equipo).
La empresa dice que, cuando los clientes necesiten dar más pasos, les informará individualmente por correo.
Pregunte a la empresa por los sitios web bloqueados y las copias de seguridad
Según las preguntas frecuentes de la empresa, los sitios web bloqueados por precaución se reabren uno a uno cuando termina un análisis de seguridad. Si restaura desde una copia de seguridad, la empresa dice que el cliente decide junto con ella qué cambios hechos desde el 27 de octubre se conservan. Los canales de contacto y la página de estado figuran en el blog de la empresa.
Operadores de servidores MCP: revisen su propia configuración
Lo que conviene comprobar en su propio servidor MCP a la luz de este incidente se resume más abajo en «Qué deben revisar los operadores de servidores MCP».
Qué ocurrió (según el anuncio de mittwald)
Esta sección se basa en la entrada oficial del blog de mittwald «Sicherheitsvorfall am MCP-Server» (Incidente de seguridad en el servidor MCP) y en sus preguntas frecuentes. Las horas son las que indica la empresa. Es el relato de la propia empresa y no ha sido verificado por un tercero.
21 de octubre (tarde)
El atacante prueba por primera vez un fallo en el servidor MCP. La empresa escribe que fue más o menos al mismo tiempo que la discusión sobre PHP2Shell.23 de octubre
El atacante empieza a actuar como un usuario normal: registra cuentas de prueba, usa extensiones y prueba intentos de inyección sencillos (la empresa).27 de octubre, 14:58 a 15:03
El atacante registra otra cuenta a las 14:58 y explota el fallo del servidor MCP a las 15:03. La empresa trata como comprometidos todos los datos desde el 27 de octubre en adelante.4 de noviembre
Por la mañana la empresa nota un comportamiento inusual en uno de sus sistemas. Bloquea la primera cuenta del atacante a las 11:11 y pone su página de estado en «investigando» a las 12:53. Identifica el servidor MCP como punto de entrada y lo apaga. Por la tarde mStudio vuelve a estar en línea. Los proyectos web siguieron accesibles todo el tiempo.5 de noviembre
Poco después de medianoche la empresa bloquea los proyectos con rastros del atacante, desactiva temporalmente el registro de cuentas nuevas y, durante el día, bloquea el inicio de sesión en mStudio y el acceso SSH a los proyectos de clientes.Durante la investigación
Especialistas externos en análisis forense de TI apoyan el análisis, y la empresa informa a las autoridades competentes.6 de noviembre
La empresa examina forensemente los 56 proyectos comprometidos y el servidor MCP. Los análisis repetidos no hallan más proyectos comprometidos y actualmente no puede detectar actividad del atacante. mStudio vuelve a ser utilizable durante la noche.7 de noviembre
mStudio y el acceso SSH vuelven a estar disponibles. Los sitios web bloqueados por precaución siguen bloqueados por ahora. La empresa dice que el centro de clientes y los sitios web gestionados allí no se vieron afectados. Se puede configurar passkeys.
Desde el 21 de octubre
Sondeo del fallo, cuentas de prueba
↓→
27 de octubre
Fallo explotado, 56 proyectos
↓→
4 de noviembre
Descubierto, servidor MCP apagado
- Punto de entrada
- Un fallo en el servidor MCP, que conecta los asistentes de IA de los clientes con el panel de control mStudio de la empresa
- Alcance del compromiso
- 56 proyectos de clientes. La empresa trata como comprometidos todos los datos desde el 27 de octubre en adelante
- Qué se leyó (preguntas frecuentes)
- No contraseñas sino tokens de sesión de usuarios del servidor MCP, todos revocados. Con un token, su poseedor podía acceder a mStudio con los derechos de ese usuario
- No afectados
- El centro de clientes y los sitios web gestionados allí. La empresa dice que no se vieron afectados en ningún momento
- Datos (preguntas frecuentes)
- No hay señales de que se publicaran datos en internet, pero la revisión continúa. Se informará individualmente a los clientes de los que se hallen señales de que se recuperaron archivos, bases de datos o buzones. Sin ese mensaje, actualmente no hay señales de acceso a ese proyecto
- Sobre el uso de IA
- La empresa dice que los pasos en sus registros se sucedían con segundos de diferencia y, según los informes, el atacante se movió por los sistemas muy rápido. La empresa dice que esto sugiere el uso de herramientas de IA. Es una sospecha de la empresa
- Respuesta de la empresa
- Bloqueo de cuentas y proyectos, desactivación del registro, bloqueo del inicio de sesión y de SSH, revocación de accesos, apagado del servidor MCP, análisis repetidos. Especialistas externos en análisis forense de TI apoyan el análisis. Se informó a las autoridades competentes
- Siguiente
- La semana siguiente, cuando el análisis y la recuperación estén totalmente completos, publicará un relato detallado. La información llegará por la página de estado y por correo
Qué se sabe y qué no
El estado a 10 de noviembre de 2026. Actualizaremos la columna de estado cuando se publique más.
| Elemento | Contenido | Estado |
|---|---|---|
| Punto de entrada | Un fallo en el servidor MCP | Confirmado (la empresa) |
| Proyectos de clientes comprometidos | 56 | Confirmado (la empresa) |
| Periodo tratado como comprometido | Datos desde el 27 de octubre en adelante | Confirmado (la empresa) |
| Descubrimiento y apagado | 4 de noviembre; servidor MCP apagado | Confirmado (la empresa) |
| Información leída | Tokens de sesión de usuarios del servidor MCP. Contraseñas no leídas. Todos revocados | Confirmado (preguntas frecuentes de la empresa) |
| Centro de clientes y sitios gestionados allí | No afectados | No incluidos (la empresa) |
| Situación a 6 de noviembre | No se hallaron más proyectos comprometidos; no se detecta actividad del atacante | Confirmado (la empresa) |
| Acceso a datos de clientes (archivos, bases de datos, correo) | Se informará individualmente a los clientes con señales de recuperación; la revisión continúa | En investigación |
| Publicación de datos | Sin señales de que se publicaran en internet | Confirmado (preguntas frecuentes de la empresa; la revisión continúa) |
| Uso de herramientas de IA | Una inferencia a partir de la velocidad en los registros; sin pruebas directas | Posible (la empresa) |
| Detalles y ubicación del fallo | No publicados | No se indica |
| Regreso del servidor MCP | Se decidirá tras la investigación | En investigación |
| Informe detallado | Previsto para la semana siguiente | Previsto (la empresa) |
Cómo leer esto: el relato de la empresa no ha sido verificado por un tercero
La cifra de 56 y la cronología proceden de la propia investigación de la empresa. La empresa dice que especialistas externos en análisis forense de TI apoyan el análisis, pero sus conclusiones no se han publicado. El uso de IA es una sospecha que la empresa extrajo de la velocidad, no un hecho confirmado. La prensa dice que tampoco está claro si el fallo estaba en el código de la empresa o en una biblioteca de código abierto.
Qué puede ocurrir cuando un servidor MCP se conecta con entornos de clientes
Lo siguiente es general y no significa que haya ocurrido aquí. Lo que la empresa ha publicado como ocurrido se limita a «Qué ocurrió» más arriba.
MCP (Model Context Protocol) es una forma de que los asistentes de IA llamen a servicios externos. Conectado a un servicio que puede operar sobre servidores y bases de datos, como un panel de control de alojamiento, un servidor MCP se convierte en una puerta para actuar en nombre de los usuarios.
Si la autenticación o las comprobaciones de entrada en esa puerta tienen un fallo, los permisos que la puerta posee pueden llegar a los tokens y operaciones de otros usuarios. En este caso, lo que la empresa dice que se leyó fueron los tokens de sesión de los usuarios, y con un token su poseedor podía entrar en el panel de control con los derechos de ese usuario. Cuanto más amplios son los permisos del token, a más proyectos puede llegar un fallo en una sola puerta.
Qué deben revisar los operadores de servidores MCP
Esta sección no evalúa la respuesta de la empresa, ni adivina el contenido o la causa del fallo. A partir de la cronología publicada y de la naturaleza general de los servidores MCP, se limita a puntos que comprobar en su propia configuración, y son nuestra opinión.
Acote los tokens que da al servidor MCP a cada finalidad
En esta cronología, los tokens que se leyeron se convirtieron tal cual en permisos del panel de control (preguntas frecuentes de la empresa). Limite los tokens que un servidor MCP recibe o emite a lo que necesita la tarea del asistente de IA, como solo lectura o un único proyecto, y manténgalos separados de los derechos de administrador. Así el alcance de una filtración es menor (nuestra opinión).
Haga los tokens de corta duración y prepare la revocación antes de un incidente
La empresa respondió revocando todos los tokens que se leyeron. Una caducidad más corta acorta el tiempo durante el que un token filtrado puede usarse. Cree y ensaye antes de un incidente un procedimiento para revocar tokens en bloque (nuestra opinión).
Detecte la fase de sondeo, antes del abuso real
En el relato de la empresa hubo una primera prueba el 21 de octubre, registros de cuentas de prueba desde el 23 de octubre e intentos de inyección sencillos, y el fallo se explotó realmente el 27 de octubre. Las alertas por ráfagas de registros de cuentas nuevas, errores anormales en las entradas y llamadas pesadas desde una sola cuenta podrían detectar la fase de sondeo (nuestra opinión).
Trate la velocidad como señal de automatización en sus registros
La empresa tomó los pasos con segundos de diferencia como pista del uso de herramientas de IA. Sea IA o no, que las operaciones continúen desde una cuenta a una velocidad que ningún humano podría seguir es útil para detectar. Ponga un techo a la tasa de operaciones por cuenta y pare o pida confirmación cuando se supere (nuestra opinión).
Mantenga una alternativa para cuando apague el servidor MCP
La empresa apagó el servidor MCP y remite a los clientes a su herramienta de línea de comandos (CLI). Mantener una forma de trabajar que no use MCP acelera la decisión de cerrar una puerta (nuestra opinión). Otro caso de IA actuando de forma autónoma en un ataque se explica en La intrusión en Hugging Face (en inglés).
Fuentes (registros públicos)
Los hechos de este artículo proceden de la siguiente información pública. No se tratan detalles de pasos de ataque.
- mittwald, «Sicherheitsvorfall am MCP-Server» (blog oficial, en alemán; cronología hasta el 7 de noviembre) — mittwald.de
- mittwald, «MCP-Server: Was du jetzt wissen musst» (preguntas frecuentes oficiales, en alemán; consultadas el 10 de noviembre) — mittwald.de
- The Record, «Alleged AI-aided cyberattack exploits assistant interface to breach German web host» (informe de prensa, de apoyo; 9 de noviembre de 2026, en inglés) — therecord.media
Historial de actualizaciones
2026-11-10: Primera versión. Basada en la entrada oficial del blog de mittwald (cronología hasta el 7 de noviembre), sus preguntas frecuentes e informes de prensa. Actualizaremos cuando se publique el informe detallado que la empresa prevé para la semana siguiente.
Lectura recomendada
- Plataformas de inferencia de IA vulneradas: El fallo del motor de inferencia de NEAR AI / El incidente de seguridad de Fireworks AI
- IA actuando de forma autónoma en un ataque: La intrusión en Hugging Face (2026) (en inglés)
- Una distribución comprometida de herramientas de IA: LiteLLM 1.107.0 distribuyó un ladrón de credenciales
- Cuando se vulnera a un proveedor de alojamiento: Cómo responder a la brecha de un proveedor de alojamiento
- Autenticación multifactor: Primeros pasos con la autenticación multifactor / Qué es una passkey
- Otros incidentes de 2026: Filtraciones de datos y ciberataques de 2026 (en inglés)