Los equipos de seguridad que utilizan asistentes de codificación de IA podrían estar exponiendo sus credenciales más potentes sin saberlo. Un nuevo estudio demuestra que los servidores del Protocolo de Contexto de Modelo (MCP) pueden cambiar silenciosamente su propio código después de haber sido configurados.

Si un atacante envenena aunque sea un solo paquete de esa cadena, podría robar claves API e inicios de sesión de administrador. Los servidores MCP permiten que los asistentes de IA se comuniquen con otras herramientas, como firewalls, plataformas SIEM y consolas en la nube.

Para realizar este trabajo, normalmente poseen las claves de la persona que los instaló. Los atacantes ya saben esto. Un servidor MCP malicioso encontrado en estado salvaje ha demostrado lo fácil que es que una herramienta confiable filtre datos.

Investigadores de Corelight notaron esta debilidad mientras revisaban la estación de trabajo de un administrador. No encontraron malware allí.

Encontraron asistentes de IA ejecutando servidores MCP con acceso privilegiado, y preguntaron de dónde provenía el código de esos servidores y cómo se actualizaba. La respuesta está en la investigación de Corelight, publicada el 10 de noviembre de 2026.

Los hackers podrían explotar las debilidades de la cadena de suministro de los servidores MCP

Los asistentes iniciaron sus servidores MCP con una herramienta de un solo paso llamada uvx. Esta descarga un paquete de Python y lo ejecuta desde una única línea de configuración. Los ajustes parecían seguros, porque nombraban una versión exacta, un número de versión o un commit de Git.

El problema es que fijar el paquete principal no fija los paquetes que están debajo de él. Un servidor comunitario había fijado sus siete dependencias directas e incluso había publicado un archivo bloqueado por hash.

Pero el lanzador ignoró ese archivo y obtuvo aproximadamente otros 60 paquetes actualizados desde el Índice de Paquetes de Python (PyPI) cada vez que reconstruía su entorno.

Durante cinco semanas, ese único servidor se reconstruyó 19 veces y produjo 15 conjuntos diferentes de dependencias. De sus 69 paquetes, 23 cambiaron de versión, incluyendo la biblioteca de criptografía y el propio kit de software MCP.

uvx --from git+https://github.com/<owner>/<server>@<release-tag> <server>

Nadie había tocado la configuración. Corelight observó la misma deriva en cada servidor lanzado de esta manera. Cada uno de esos paquetes se ejecuta dentro del mismo proceso que el servidor.

Eso significa que cualquiera de ellos puede leer los tokens de la API, los archivos del usuario y las rutas de red a las que el servidor tiene acceso. Una actualización maliciosa ni siquiera necesita ser llamada.

Algunos paquetes maliciosos se ejecutan en el momento en que Python se inicia. El riesgo no se limita a Python. Algunos proveedores indican a los usuarios que inicien un proxy local con npx y una etiqueta "latest" (última versión).

Esto descarga la versión más reciente en cada inicio. También replica el fallo crítico de mcp-remote calificado con 9.6 en la escala CVSS, donde las actualizaciones rápidas ayudaron, pero una versión secuestrada se propagaría con la misma velocidad.

Corelight subrayó que esto no es un fallo del MCP en sí. Cada caso derivó de una elección de configuración. De los 35 servidores MCP que revisaron, 23 tenían una instalación recomendada que descargaba dependencias actualizadas desde un registro público.

Por qué los secuestros de paquetes empeoran esto

Los atacantes van a por la dependencia que sea más fácil de tomar. Podría ser una cuenta de mantenedor con una contraseña reutilizada, un token obtenido mediante phishing o una tubería de lanzamiento débil.

La versión maliciosa entonces parece una actualización normal. Corelight señaló casos pasados como xz Utils, Ultralytics y Nx, donde los tokens y claves robadas fueron el premio.

El gusano npm Shai-Hulud es un ejemplo reciente. Utilizó tokens de npm robados para publicar versiones infectadas de cada paquete que mantenía una víctima.

Una variante de junio de 2026 llegó a PyPI y fue a por credenciales de la nube, tokens de GitHub y claves API para herramientas de codificación de IA. En una oleada, seis versiones maliciosas estuvieron activas durante menos de 30 minutos.

Un servidor que se reconstruye cada pocos días, y que se inicia por su cuenta, tiene más posibilidades de caer en una ventana como esa. Este patrón coincide con informes más amplios sobre cómo los atacantes envenenan las actualizaciones de software confiables para alcanzar secretos de desarrolladores y de la nube.

Una actualización gestionada tiene una compilación que tú controlas y un número de versión que puedes ver. Un lanzador que se reconstruye al iniciar no ofrece ninguna de las dos cosas, y el número de versión del propio servidor nunca cambia.

Corelight mostró cómo detectar el problema. Los registros de DNS y TLS enumeran los hosts que contactan con GitHub, PyPI y npm. En su laboratorio, eso dejó cuatro hosts.

Los datos del endpoint mostraron entonces que solo la estación de trabajo del administrador instalaba paquetes de PyPI, y lo hacía cada vez que un asistente de IA iniciaba sus servidores. Esos servidores realizaron más de 1,600 conexiones en una semana a 11 sistemas de gestión.

La solución es congelar el entorno. Los equipos deberían fijar un commit, instalar desde un archivo de bloqueo fijado por hash, lanzar el servidor directamente y desactivar las comprobaciones de actualización al inicio.

Corelight congeló cinco servidores y los inició 457 veces durante dos semanas, y sus listas de paquetes nunca cambiaron. Cada servidor también debería tener su propia cuenta con el acceso mínimo necesario, y un propietario designado debería revisar las actualizaciones según un calendario.