El contrato MCP por sí solo no limita el acceso al sistema de archivos

Un servidor MCP puede anunciar una tarea estrecha y, al mismo tiempo, ejecutarse en un proceso que hereda un acceso mucho más amplio al host. La diferencia entre la función descrita y la capacidad efectiva es un límite de seguridad que no puede resolverse solo con el schema de la herramienta.

Estado: Evidence Brief aprobado para publicación. Serie editorial: Papers que leemos por ti. Este texto analiza el preprint *MCP Security at Scale*. No expone servidores vulnerables, rutas, credenciales, payloads ni instrucciones de explotación; tampoco afirma que todo servidor MCP sea inseguro ni que el estudio haya medido efectos fuera de las respuestas observadas.

El catálogo no es el denominador de la confirmación dinámica

Los autores consolidaron 21.097 servidores de nueve registros. Identificaron 17.919 proyectos open-source y ejecutaron la medición de alcance local en 7.222. Tras el triage, 4.806 servidores pasaron a análisis profundo y 4.292 tuvieron análisis estático.

En 787 de los 4.806 servidores triados, o 16,4%, apareció una señal de nivel L1: la implementación tenía capacidad de sistema de archivos, pero la descripción pública no declaraba una categoría explícita de FileSystem. Es una señal de desalineación entre contrato y capacidad, no una confirmación de explotación o fuga.

Se confirmaron 150 instancias, sin una tasa universal

El pipeline confirmó dinámicamente 150 instancias mediante un protocolo de tres casos. En 136, la respuesta contenía el marcador exacto de credencial usado por los investigadores; en 14 hubo otra evidencia observable. El paper no proporciona un denominador que permita convertir las 150 confirmaciones en una tasa de prevalencia sobre los 21.097 servidores, los 17.919 proyectos open-source o los 7.222 alcanzados.

La lectura correcta es que hubo casos reales confirmados dentro de una selección dirigida por el pipeline. La lectura incorrecta sería que un porcentaje equivalente de todo el ecosistema es vulnerable.

Divulgación coordinada y correcciones upstream

Los autores prepararon 13 paquetes de divulgación. Dos fallos recibieron CVE y correcciones upstream:

1. CVE-2025-68143 / GHSA-5cgr-j3jf-jw3v, corregida en la versión indicada por el advisory el 25/09/2025.
2. CVE-2026-27735 / GHSA-vjqx-cfc4-9h6v, corregida en la versión indicada por el advisory el 14/01/2026.

Estos advisories corroboran dos incidencias específicas. No validan toda la metodología ni convierten los demás hallazgos en vulnerabilidades confirmadas por terceros.

El contrato de herramienta no es un sandbox

El nombre, la descripción y el schema ayudan al modelo a decidir cuándo llamar una herramienta. No eliminan permisos del proceso que implementa el servidor. Si ese proceso hereda el directorio del usuario, variables de entorno, sockets o credenciales, el límite real es el conjunto de capacidades del runtime.

Un contrato ejecutable mínimo debe separar:

1. Intención declarada: qué promete hacer la herramienta y qué datos espera.
2. Capacidad concedida: archivos, red, procesos, secretos e identidades disponibles para el runtime.
3. Política de llamada: quién puede invocar, en qué contexto y con qué argumentos.
4. Efecto observado: recursos realmente leídos, escritos, enviados o modificados.
5. Aceptación y revocación: evidencia exigida para promover, limitar o retirar la integración.

Controles proporcionales

• ejecute cada servidor con identidad y directorios mínimos, preferiblemente en su propio aislamiento;
• use allowlists de rutas y destinos, denegando acceso por defecto;
• inyecte secretos de corta duración solo en la llamada que los exige;
• valide descripciones y schemas contra comportamiento observado en un entorno controlado;
• registre llamadas, capacidades concedidas y efectos sin almacenar contenido sensible;
• pruebe actualización, revocación y rollback antes de permitir uso autónomo;
• trate un cambio de dependencia o imagen como una nueva revisión de límite.

Límites y conflicto de interés

Solo el 34,2% de los proyectos open-source catalogados llegó a la medición de alcance local. Tras ese filtro, el 97% de la muestra ejecutable se concentró en Node y Python, y el 84% de los servidores iniciados provino de un único registro. Esta selección limita la generalización.

Los límites de capacidad se infirieron mediante análisis y experimentos; no constituyen una medición completa de todos los efectos del sistema operativo. El protocolo cubrió herramientas y secuencias seleccionadas, usó juicios de LLM en partes del pipeline y observó divulgación a través de la respuesta, por lo que puede perder efectos laterales silenciosos. El sandbox macOS Seatbelt usado por los investigadores no prueba equivalencia con otros sistemas operativos o entornos de producción.

Los autores declaran afiliaciones con University of Illinois Urbana-Champaign, Santa Clara University, Auburn University at Montgomery y actividad independiente. No encontramos una declaración explícita de financiación o conflicto de interés en el texto consultado. Hasta el corte editorial, no encontramos una reproducción independiente completa del estudio.

regla de arquitectura

Forge debe tratar MCP como código de terceros con capacidades, no como una descripción confiable de intenciones. La promoción exige probar juntos contrato, identidad, aislamiento, telemetría y revocación. Si el proceso puede alcanzar un recurso, esa capacidad pertenece al modelo de amenazas aunque no aparezca en el nombre de la herramienta. [R2-C3]

Fuentes directas

1. MCP Security at Scale — arXiv. Preprint, autores, resumen, versión y fecha.
2. MCP Security at Scale — texto completo. Método, embudo, resultados, limitaciones y divulgación coordinada.
3. GHSA-5cgr-j3jf-jw3v. Advisory público de la incidencia CVE-2025-68143.
4. GHSA-vjqx-cfc4-9h6v. Advisory público de la incidencia CVE-2026-27735.

Nota editorial y de responsabilidad

Este texto combina hechos atribuidos a las fuentes con análisis y propuesta técnica del autor. Los puntos de vista personales y profesionales no son hechos comprobados; los datos, denominadores, límites, afiliaciones y ausencia de reproducción independiente se indican cuando están disponibles. El contenido es informativo y no sustituye una evaluación técnica, jurídica, regulatoria o de seguridad. MCP, proyectos, productos e instituciones citados pertenecen a sus titulares; no hay patrocinio ni respaldo. No se reproduce ningún objetivo, secreto o procedimiento ofensivo. Tech Human y Trustyu operan comercialmente en desarrollo y gobernanza de productos digitales. La investigación, estructura y redacción tuvieron asistencia de IA; Fernando Parreiras autorizó la revisión factual, aprobación autoral y publicación el 16/10/2026, sin revisión humana independiente adicional.

Corte de investigación: 16/10/2026. Estado editorial: Evidence Brief especial autorizado para el 17/10/2026 a las 09:00 BRT.