Vulnerabilidades de seguridad en servidores MCP en 2026:
30 CVE, sin autenticación, sin cifrado

Entre enero y febrero de 2026, investigadores de seguridad revelaron 30 CVE contra servidores del Model Context Protocol (MCP) — la capa de infraestructura que conecta los asistentes de codificación con IA a bases de datos, API y sistemas de archivos. La gravedad más alta alcanzó CVSS 9.6 (crítica), lo que permitía la ejecución remota de código sin autenticación. Esta es la crisis de seguridad que los desarrolladores de IA agéntica deben comprender antes de que llegue a producción.

What is MCP and why does it matter for security?

Model Context Protocol is Anthropic's open standard for connecting AI assistants to external tools and data sources. In practice, an MCP server is a local or remote process that your AI coding assistant (Cursor, Claude Desktop, VS Code with GitHub Copilot, Windsurf, Cline) communicates with via JSON-RPC to call tools like "read this file", "query this database", "fetch this API endpoint".

The security problem is structural. MCP was designed for developer convenience, not for production security. The specification has no built-in authentication mechanism, no transport encryption requirement, and no permission scoping standard. Every security control is left as an implementation detail — and many implementations skip them entirely.

Los 30 CVE: qué se encontró

Investigadores de seguridad de varias empresas realizaron auditorías sistemáticas de los servidores MCP más populares y del propio protocolo entre enero y febrero de 2026. Los 30 CVE revelados se agruparon en seis categorías:

Why 38% of MCP servers have no authentication

The authentication gap is not developer negligence — it is a documentation and design problem. The official MCP specification does not mandate authentication, and the reference implementation examples do not include it. Developers following the quickstart documentation ship unauthenticated servers because the documentation does not tell them otherwise.

The situation is compounded by the deployment model. Most MCP servers run locally — on the developer's workstation, on localhost, in a Docker container. The implicit assumption is that local access equals trusted access. This assumption breaks in three common scenarios:

• Multi-user development environments (shared cloud VMs, pair programming setups) where "localhost" is accessible to multiple users
• Browser-based attacks where a compromised web page makes requests to 127.0.0.1:3000 from inside the browser sandbox
• Malware on the developer machine that discovers and communicates with MCP servers to extend its capabilities

Remote MCP deployments — where the server runs on a cloud host and the AI assistant connects via HTTPS — are rarer but face the full spectrum of web application vulnerabilities, compounded by the lack of standard auth in the MCP spec.

The PII risk in unprotected MCP deployments

MCP servers by design have access to developer context: the codebase, the database connection strings, the API keys, the customer data files. This is what makes them powerful. It also makes them high-value targets.

When an AI coding assistant calls an MCP server to query a database or read a file, it may be passing personal data — customer names, email addresses, financial records — through the MCP JSON-RPC transport. If that transport is unauthenticated and unencrypted, any observer on the local network (or any process on the local machine) can read that data.

Los CVE de envenenamiento de herramientas son especialmente peligrosos para los datos personales. Un atacante capaz de inyectar una descripción de herramienta maliciosa en un servidor MCP —por ejemplo, modificando un archivo de configuración MCP compartido en un repositorio— puede indicar al asistente de IA de cada desarrollador que incluya datos sensibles en su próxima llamada saliente a una herramienta. El desarrollador nunca ve la exfiltración; parece un comportamiento normal del asistente de IA.

Lista de verificación para el endurecimiento de la seguridad de MCP

Hasta que la especificación de MCP se actualice para incluir autenticación obligatoria y seguridad en el transporte, los desarrolladores deben implementar controles en la capa de despliegue. Esta es la lista mínima de endurecimiento para despliegues de MCP en producción:

• Autenticación por token en cada endpoint — Añada validación de token portador (bearer) a todas las rutas del servidor MCP. Genere un secreto aleatorio de 32 bytes al iniciar, guárdelo únicamente en variables de entorno y valídelo en cada solicitud. Nunca lo codifique de forma fija (hardcode).
• TLS para todos los despliegues remotos — Si su servidor MCP no se ejecuta en localhost, debe usar HTTPS. Use Let's Encrypt o un certificado gestionado. Nunca despliegue MCP mediante HTTP sin cifrar en un host remoto.
• Vinculación exclusiva a localhost — Los servidores MCP locales deben vincularse a 127.0.0.1, no a 0.0.0.0. Vincularse a todas las interfaces expone el servidor a toda la red local.
• Integridad de las descripciones de herramientas — Si su servidor MCP carga descripciones de herramientas desde fuentes externas (archivos de configuración, URL remotas, entradas de usuario), valídelas y sanitícelas antes de usarlas. Nunca ejecute descripciones de herramientas procedentes de fuentes no confiables sin revisarlas.
• Principio de mínimo privilegio para las herramientas — Cada herramienta MCP debe tener los permisos mínimos necesarios. Una herramienta de lectura de archivos no debería tener permisos de escritura. Una herramienta de base de datos debería usar una conexión de solo lectura para las operaciones de lectura.
• Anonimización de datos personales en la capa del protocolo — Enrute todas las entradas y salidas de MCP a través de un proxy consciente de los datos personales (como el MCP Server de anonymize.dev) que elimine los datos personales antes de que entren en el contexto del modelo de IA y antes de que aparezcan en los parámetros de las llamadas a herramientas.
• Registro de auditoría para las llamadas a herramientas — Registre cada llamada a herramienta con marca de tiempo, nombre de la herramienta, identidad del llamante (si está autenticado) y hash de los parámetros (no los parámetros completos, que pueden contener datos sensibles). Supervise patrones anómalos de llamadas a herramientas.
• Fijación de dependencias y comprobaciones de integridad — Los paquetes de servidores MCP son dependencias de npm/pip. Fije versiones exactas y verifique los checksums. La superficie de ataque de la cadena de suministro para las herramientas MCP no está actualmente auditada.
• Instancias MCP independientes por proyecto — No reutilice una única configuración de servidor MCP entre proyectos con diferentes niveles de sensibilidad de datos. Un servidor con acceso a datos de clientes en producción no debería servir al mismo contexto de agente que un sandbox de desarrollo.
• Supervisión periódica de CVE — Suscríbase a los avisos de seguridad de GitHub de @modelcontextprotocol y a los avisos de seguridad de los paquetes correspondientes (@modelcontextprotocol/server-*, paquetes de la comunidad). La ola de 30 CVE es la primera, no la última.

Cómo anonymize.dev aborda la brecha de seguridad estructural de MCP

El MCP Server de anonymize.dev funciona como un proxy de privacidad dentro de la cadena del protocolo MCP. En lugar de conectar su asistente de IA directamente a sus herramientas, usted enruta la conexión a través del MCP Server de anonymize.dev, que:

1. Intercepta todos los parámetros de las llamadas a herramientas entrantes y los analiza en busca de datos personales mediante más de 267 detectores de tipos de entidad en 48 idiomas
2. Sustituye los datos personales identificados por marcadores de posición estructurados ([PERSON_1], [EMAIL_1], etc.) antes de reenviarlos a la herramienta subyacente
3. Intercepta todas las respuestas de las herramientas y las desanonimiza antes de devolverlas al asistente de IA
4. Mantiene un almacén cifrado de correspondencias por sesión para que la desanonimización de ida y vuelta no pierda información

Esta arquitectura implica que, incluso si el servidor MCP subyacente se ve comprometido —mediante envenenamiento de herramientas, path traversal o acceso sin autenticación—, el atacante solo ve marcadores de posición anonimizados, no datos personales reales. El objetivo de exfiltración más valioso (los datos personales) está estructuralmente ausente de la capa del protocolo.

tool_call("query_db", {"where": "email = 'alice@company.com'"})

tool_call("query_db", {"where": "email = '[EMAIL_1]'"})

El enfoque de anonymize.dev no elimina la necesidad de autenticación y TLS —esos controles deben seguir implementándose—. Pero proporciona la defensa crítica en la capa de datos que la propia especificación de MCP no puede exigir: garantizar que incluso un despliegue de MCP totalmente comprometido no tenga datos personales que exfiltrar.