Seguridad MCP Google: La falla SSRF y la confianza entre agentes
La seguridad MCP Google volvió a la conversación por fallos SSRF en herramientas de agentes. No significa que todo servidor MCP sea vulnerable: una entrada puede cruzar límites si una herramienta la convierte en una petición de red sin validación. El caso reúne un componente identificable, versiones afectadas y una corrección pública, mientras la revisión de octubre agrupa reportes con estados distintos. Distinguir esas pruebas explica el riesgo de delegación entre agentes sin afirmar que cada instalación esté comprometida ni que todos los hallazgos compartan causa. También ofrece pasos de actualización y revisión.
Qué ocurrió en el componente HTTP
Ars Technica publicó el 5 de octubre una revisión de hallazgos acumulados, no una vulnerabilidad descubierta ese día. Rapid7 registra la SSRF de Google MCP Toolbox en versiones previas; Google corrigió el problema en junio. La fuente base es la aviso técnico de Rapid7.
SSRF ocurre cuando una aplicación induce a su servidor a solicitar destinos que el usuario no debería alcanzar. El impacto depende de permisos de red, validación de URL, redirecciones y datos accesibles.
En el componente HTTP de MCP Toolbox, el cliente podía seguir redirecciones sin una política restrictiva y no validaba las IP de destino. Un parámetro elaborado podía conducir a endpoints internos.
El aviso de Rapid7 describe versiones afectadas e impacto; el cambio de Google en GitHub documenta defensas para validar direcciones, restringir rangos y rechazar bases URL inseguras al inicio.
La seguridad MCP Google no debe confundirse con CVE-2026-97228 de Rapid7, una inyección GraphQL en otro producto. La investigación los agrupa como fallos de agentes, pero no comparten componente ni causa.
El investigador llama “protocol pivoting” a casos donde instrucciones pasan de un protocolo a otro y conservan confianza indebida. Es una clase de riesgo propuesta, no una categoría formal ni prueba de vulnerabilidad.
Google: cómo se propaga el riesgo entre protocolos
Los sistemas con varios agentes delegan tareas: uno interpreta contenido y otro opera una herramienta. Si el segundo asume que una solicitud delegada es confiable, una instrucción no validada puede ampliar su alcance.
El fallo puede aparecer entre validación de argumentos, redirecciones HTTP, resolución DNS, listas permitidas y privilegios. Cada capa debe conservar las restricciones relevantes al transferir el control.
La protección SSRF debe evaluar el destino real al conectarse, no solo el texto inicial de una URL. Una redirección o resolución DNS cambiante puede eludir una comprobación superficial.
La revisión de Google en GitHub implementa una barrera para esos casos en la fuente HTTP de Toolbox. Los equipos que operan versiones afectadas deben consultar los avisos del proyecto, identificar su versión exacta y aplicar la actualización correspondiente antes de confiar en filtros propios.
Actualizar corrige esa implementación, pero no demuestra que todos los sistemas MCP o A2A tengan la falla. Límites de red y permisos deben probarse por producto, versión y configuración.
La seguridad MCP Google también depende de qué datos puede consultar la herramienta y con qué identidad se ejecuta. Aun si un destino interno responde, el impacto potencial está condicionado por credenciales, segmentación, alcance de red y controles que el servicio tenga autorizados.
Controles y límites de la evidencia
Google presenta los agentes en su blog oficial, aunque ese contexto no prueba esta falla. Consulta el cambio de código de Toolbox, el aviso CVE de Rapid7, las noticias tecnológicas y el sitio de Gazu.
Los equipos deben revisar esquema y host, bloquear IP privadas y metadatos, volver a comprobar redirecciones, evitar DNS rebinding, proteger registros y aplicar privilegios mínimos.
La delegación entre agentes requiere además transportar procedencia y permisos. Un agente receptor no debería aceptar una orden solo porque llegó desde otro componente interno; necesita conocer quién la originó, qué datos la influyeron y qué operaciones están permitidas.
La investigación describe reportes de varias organizaciones, pero sus estados difieren: algunos se corrigieron, otros tienen CVE y ciertos casos siguen en triage. No deben presentarse como hallazgos equivalentes.
El caso exige inventariar herramientas, limitar conexiones salientes, probar redirecciones y actualizar dependencias. La seguridad MCP Google muestra por qué la frontera entre agente y herramienta requiere controles explícitos.
Para comprobar la seguridad MCP Google, coteja la versión instalada con el aviso y verifica en pruebas que el servicio no alcance destinos internos no autorizados. El parche del proyecto no sustituye estos controles locales.
Google presenta su trabajo sobre agentes en el blog oficial, aunque eso no valida esta vulnerabilidad. Revisa el cambio de Google y el aviso CVE de Rapid7. Lee más noticias tecnológicas y visita el sitio de Gazu.
Implementación de Agentes de IA & Automatización de Procesos
Lleve la productividad de su empresa al siguiente nivel. Diseñamos e integramos agentes inteligentes a la medida para automatizar su flujo de ventas, atención al cliente y operaciones repetitivas de forma 100% segura.
Preguntas frecuentes sobre seguridad de agentes
1. ¿Qué vulnerabilidad corrigió Google MCP Toolbox?
El aviso describe una SSRF en el componente HTTP de versiones afectadas: redirecciones y destinos IP no estaban restringidos con suficiente rigor. Google añadió validación de IP y límites de red para rechazar destinos inseguros antes de enviar solicitudes, según el cambio del repositorio.
2. ¿La seguridad MCP Google significa que todos los MCP son vulnerables?
No. La seguridad MCP Google aquí se refiere a componentes y versiones determinados de Toolbox. Otros servidores deben evaluarse por sus argumentos, permisos, red, redirecciones y actualizaciones; este caso no prueba una vulnerabilidad universal. Los avisos concretos determinan si una instancia requiere actualización.
3. ¿Qué es protocol pivoting en esta investigación?
Es el nombre que el investigador da a ataques donde una entrada pasa entre protocolos o agentes y pierde controles de confianza. Es una descripción de una clase de riesgo, no un diagnóstico automático aplicable a toda integración entre agentes.
El alcance real del caso
El caso de Google demuestra una falla concreta y una corrección identificable; la investigación más amplia plantea riesgos de diseño que cada equipo debe verificar en su arquitectura. La conclusión responsable es revisar permisos y destinos, no declarar inseguros todos los agentes.
