CVE-2026-46519: cuando un servidor MCP filtra herramientas al mostrarlas pero no al ejecutarlas

¿Qué es esto?

CVE-2026-46519 es una elusión de control de acceso en mcp-server-kubernetes, un servidor Model Context Protocol (MCP) muy utilizado que permite a los agentes de IA operar un clúster de Kubernetes. El fallo se publicó mediante el aviso de seguridad de GitHub GHSA-cr22-wjx7-2w6m y se registró en el NVD con una puntuación CVSS 3.1 de 8.8 (alta) y una clase de debilidad CWE-863 (autorización incorrecta). NeuralTrust publicó un análisis técnico el 19 de mayo de 2026, la GitLab Advisory Database lo registró el 21 de mayo de 2026, y se corrigió en la versión 3.6.0.

El paquete no es marginal: acumula unas 20 000 descargas semanales en npm y es el puente estándar al que recurren las organizaciones cuando quieren que un agente lea o gestione el estado de un clúster. Es ese alcance lo que convierte un pequeño desliz lógico en un problema a escala de clúster.

Cómo funciona

El servidor expone tres variables de entorno documentadas como controles de acceso: ALLOW_ONLY_READONLY_TOOLS, ALLOW_ONLY_NON_DESTRUCTIVE_TOOLS y ALLOWED_TOOLS (una lista blanca explícita de nombres de herramientas). Un operador que establece ALLOW_ONLY_READONLY_TOOLS=true espera que un agente conectado pueda mirar, pero nunca tocar.

MCP divide el uso de herramientas en dos operaciones: tools/list (descubrimiento — «¿qué puedo hacer aquí?») y tools/call (ejecución — «haz esto ahora»). El defecto: la lógica de restricción vivía solo en tools/list.

Capa                    Solicitud      ¿Restricción verificada?
----------------------  -------------  ------------------------
Descubrimiento (vista)  tools/list     SÍ  -> se devuelve lista filtrada
Ejecución (acción)      tools/call     NO  -> se ejecuta cualquier herramienta nombrada

Cuando un agente de solo lectura pedía su lista de herramientas, el servidor devolvía correctamente un conjunto filtrado — kubectl_get, kubectl_describe y similares — sin las herramientas destructivas como kubectl_delete, exec_in_pod o kubectl_generic. Pero el manejador tools/call nunca volvía a comprobar la política. Cualquier cliente que ya conociera el nombre de una herramienta restringida — y esos nombres figuran en el propio README del proyecto — podía invocarla directamente. Sin inyección, sin cadena de explotación, sin primitiva de escalada de privilegios: solo una solicitud de una herramienta que la interfaz fingía que no existía.

vista del agente: [ kubectl_get, kubectl_describe ]         # lo que muestra tools/list
alcance real    : tools/call -> kubectl_delete([REDACTED])     # lo que el servidor hará

En palabras del aviso, los controles eran «efectivamente cosméticos»: ocultaban los botones pero dejaban el cableado conectado.

Por qué importa

El radio de impacto real depende de algo que la CVE no corrige por usted: los privilegios de la Service Account de Kubernetes bajo la que se ejecuta el servidor MCP. La elusión nunca otorga al servidor más derechos de los que ya tiene — pero en clústeres de desarrollo y preproducción es común ejecutar uno de estos servidores como cluster-admin «por comodidad». En esa configuración, cualquiera que alcance el punto de acceso HTTP hereda todo el poder de esa cuenta: borrar namespaces, reescribir despliegues, leer cada Secret.

Dos lecciones trascienden el caso de un solo paquete npm. Primero, es un caso de manual de autorización en la capa de presentación frente a la de ejecución — el mismo error que una aplicación web que oculta un botón de administrador pero deja la ruta /admin sin autenticar. El instrumental de agentes, por ser joven, reinventa estos fallos. Segundo, el modelo de amenaza de MCP no se limita al «prompt malicioso». Un agente honesto pero mal configurado, o cualquier cliente en la misma red, dispara este fallo con una solicitud normal. Al momento de la divulgación no existía prueba de concepto pública, pero el fallo no exige ninguna habilidad especial para reproducirse.

Defensas

1. Actualice ahora. Pase a mcp-server-kubernetes 3.6.0 o posterior, que aplica en tools/call las mismas restricciones que ya aplicaba en tools/list. Es la única corrección que cierra la brecha real.

2. Trate el RBAC como la frontera de verdad. El «modo solo lectura» a nivel de aplicación es una comodidad, no un control. Otorgue a la Service Account del servidor el menor privilegio que realmente necesite. Si un agente solo observa pods, su SA no debe poder borrarlos — sin importar ningún interruptor de la aplicación.

3. No exponga el punto de acceso. Mantenga el servidor MCP fuera de la internet pública, accesible solo desde redes de confianza o mediante un túnel seguro, y exija autenticación fuerte (el proyecto admite MCP_AUTH_TOKEN).

4. Audite sus propios servidores de herramientas en busca de este patrón. Si construye u opera servidores MCP, verifique que cada decisión de autorización se aplica en tools/call, no solo en tools/list. El filtrado en el descubrimiento es UX; el filtrado en la ejecución es seguridad. Prueba rápida: invoque una herramienta que debería estar oculta y confirme que el servidor la rechaza.

5. Registre en la capa de ejecución. Anote las invocaciones de tools/call con el nombre de la herramienta y el resultado, para que una solicitud de una herramienta «filtrada» quede visible a posteriori, aunque falte un control.

Estado

Elemento	Referencia	Fecha	Notas
Aviso de seguridad de GitHub	GHSA-cr22-wjx7-2w6m	2026-05	Aviso de origen, corrección en v3.6.0
Registro CVE	NVD CVE-2026-46519	2026-05	CVSS 8.8 alta, CWE-863
Análisis técnico	NeuralTrust	2026-05-19	Descubrimiento vs ejecución
GitLab Advisory DB	GLAD	2026-05-21	Afectadas: todas las versiones < 3.6.0
Cobertura de prensa	TheHackerWire	2026-06-11	Sin PoC público al momento de publicar
Versión corregida	mcp-server-kubernetes	v3.6.0	Controles añadidos en la ejecución

El titular no es «MCP de Kubernetes es peligroso». Es que la autorización debe aplicarse allí donde ocurre la acción, no allí donde se dibuja el menú — una regla que la web aprendió hace veinte años y que el instrumental de agentes está reaprendiendo, una CVE cada vez.