CVE-2026-46519: Por qué tu servidor MCP de Kubernetes puede estar expuesto a ataques

Investigaciones recientes de equipos de seguridad han revelado un importante bypass de control de acceso, identificado como CVE-2026-46519, dentro del proyecto mcp-server-kubernetes. Esta vulnerabilidad tiene una calificación de severidad alta, con una puntuación CVSS de 8.8, lo que subraya su potencial impacto sobre los sistemas afectados.

Este fallo resulta especialmente preocupante dada la amplia adopción de mcp-server-kubernetes. Este proyecto actúa como un puente fundamental que permite a los agentes de IA interactuar directamente con clústeres de Kubernetes. Con más de 20.000 descargas semanales en npm y 1,4K estrellas en GitHub, representa una pieza sustancial de infraestructura de la que muchas organizaciones dependen para integrar capacidades de IA en sus entornos de Kubernetes.

El problema de fondo reside en el bypass de los controles de seguridad diseñados para limitar a los agentes de IA a acciones específicas, como ejecutar únicamente operaciones "de sólo lectura" o "no destructivas". A pesar de las configuraciones pensadas para limitar las capacidades de un agente, esta vulnerabilidad permite saltarse esas restricciones, posibilitando que el agente ejecute comandos más allá de su alcance autorizado.

Descubrimiento vs. Ejecución

La vulnerabilidad surge de una desconexión fundamental entre cómo el servidor anuncia sus capacidades y cómo realmente las ejecuta. En mcp-server-kubernetes, los operadores pueden utilizar variables de entorno para aplicar el principio de mínimo privilegio. Por ejemplo, establecer ALLOW_ONLY_READONLY_TOOLS=true está pensado para restringir al agente a operaciones de lectura, mientras que ALLOWED_TOOLS puede usarse para especificar una allowlist explícita de nombres de herramientas permitidas.

Sin embargo, estos controles solo se aplican en la capa de descubrimiento. Cuando un agente de IA o un cliente solicita la lista de herramientas disponibles mediante el método tools/list, el servidor filtra correctamente la respuesta según las variables de entorno. Un agente de "sólo lectura" únicamente verá herramientas como kubectl_get o kubectl_describe en su lista de opciones.

El fallo crítico se produce en la capa de ejecución. El handler de tools/call, responsable de ejecutar realmente la herramienta solicitada, carece de los controles correspondientes. No verifica si la herramienta llamada forma parte del conjunto permitido ni si infringe la política de "sólo lectura". En consecuencia, cualquier cliente que conozca el nombre de una herramienta restringida —y todos están públicamente documentados en el README del proyecto— puede invocarla directamente enviando una petición dirigida al endpoint tools/call.

Esta discrepancia significa que las fronteras de seguridad son puramente cosméticas. Esconden los "botones" de la interfaz de usuario, pero dejan el "cableado" subyacente totalmente accesible para cualquiera que sepa dónde mirar.

De sólo lectura a la toma de control del clúster

Para entender las implicaciones prácticas de este bypass, imagina un escenario en el que un operador despliega el servidor MCP con ALLOW_ONLY_READONLY_TOOLS=true. El operador asume que cualquier agente o cliente que se conecte a este endpoint está estrictamente limitado a consultar recursos y no puede modificar el estado del clúster.

Cuando el agente consulta al servidor por sus capacidades, recibe una lista de ocho herramientas de sólo lectura. Una herramienta destructiva como kubectl_delete está visiblemente ausente de esa lista, lo que refuerza la falsa sensación de seguridad del operador. Sin embargo, un atacante o un cliente malicioso puede simplemente ignorar la lista proporcionada y enviar una petición directa al servidor para eliminar un recurso.

Por ejemplo, un simple comando curl puede emplearse para saltarse la restricción prevista:

El servidor, al no validar la petición frente a su política de "sólo lectura", ejecuta el comando y devuelve un mensaje de éxito, confirmando que el pod ha sido eliminado. Esta demostración prueba que la red de seguridad de "sólo lectura" es completamente inefectiva en las versiones vulnerables del servidor. La restricción solo afecta a lo que se muestra al cliente, no a lo que el servidor está dispuesto a hacer.

La criticidad de los privilegios del Service Account

El impacto final de este bypass depende en gran medida de los permisos otorgados al Service Account de Kubernetes que el servidor MCP utiliza para interactuar con el clúster. Aunque la vulnerabilidad permite a un cliente saltarse las restricciones internas del servidor, no puede otorgarle al servidor más permisos de los que ya tiene dentro de Kubernetes.

En muchos entornos de desarrollo o staging, es habitual ver el servidor MCP ejecutándose con privilegios de cluster-admin por comodidad. En esa configuración, el bypass resulta catastrófico. Un atacante que pueda alcanzar el endpoint HTTP obtiene de facto el control total del clúster, ya que puede invocar cualquier herramienta que la cuenta cluster-admin esté autorizada a usar. Esto incluye eliminar namespaces, modificar deployments o incluso exfiltrar datos sensibles desde secrets.

Esta vulnerabilidad es un crudo recordatorio del Principio de Mínimo Privilegio. El Role-Based Access Control (RBAC) de Kubernetes debe ser siempre la última línea de defensa. Aunque un control a nivel de aplicación —como un "modo de sólo lectura"— falle, la cuenta de servicio subyacente solo debería tener el conjunto mínimo de permisos necesario para su función. Si un agente únicamente necesita monitorear pods, su Service Account no debería tener autoridad para eliminarlos, independientemente de lo que sugiera la configuración del servidor MCP.

Remediación y buenas prácticas para la seguridad de MCP

El paso más inmediato y crítico para cualquier organización que utilice mcp-server-kubernetes es actualizar a la versión 3.6.0 o posterior. Esta versión introduce los controles necesarios en la capa de ejecución, garantizando que el handler tools/call respete las mismas restricciones que el método tools/list. Si estás ejecutando una versión anterior, tu clúster está potencialmente en riesgo y deberías priorizar esta actualización de inmediato.

Más allá de este parche concreto, el descubrimiento de CVE-2026-46519 deja lecciones más amplias para la seguridad de los sistemas agénticos de IA. Los desarrolladores de este tipo de herramientas deben adoptar un enfoque de "no confíes en nada". Toda petición entrante, incluso si proviene de un cliente autenticado, debe tratarse como potencialmente maliciosa. Los controles de seguridad nunca deben implementarse únicamente en la capa de presentación o de descubrimiento; deben aplicarse en el punto de ejecución para ser efectivos.

Para los operadores que despliegan servidores MCP, una estrategia de defensa en profundidad resulta esencial. Esto incluye:

• Aislamiento de red: Asegúrate de que el endpoint del servidor MCP no esté expuesto a internet pública y de que solo sea accesible desde redes de confianza o a través de túneles seguros.
• Autenticación robusta: Utiliza mecanismos de autenticación fuertes, como el MCP_AUTH_TOKEN que soporta el proyecto, para controlar quién puede llegar al servidor en primer lugar.
• RBAC granular: Como ya se ha comentado, emplea siempre el Service Account de Kubernetes más restrictivo posible. Un agente de IA solo debería tener los permisos que estrictamente necesita para realizar sus tareas.

Combinando actualizaciones a tiempo con una seguridad rigurosa a nivel de infraestructura, las organizaciones pueden aprovechar de forma segura la potencia de los agentes de IA manteniendo la integridad de sus clústeres de Kubernetes.