Cuando el parche SSRF no aguanta: DNS rebinding y guardas eludidas en agentes

What is this?

Dos divulgaciones publicadas en julio de 2026 apuntan al mismo hecho incómodo: publicar un parche SSRF en un framework de agentes no equivale a estar a salvo de la SSRF. Una falla de tipo SSRF (server-side request forgery) permite a un atacante hacer que el servidor recupere una URL de su elección, normalmente para alcanzar un servicio interno o un punto de metadatos en la nube como 169.254.169.254, que puede devolver credenciales IAM.

El 2026-07-10, un aviso de GitHub sobre el servidor MCP mcp-atlassian describió una forma de vencer una guarda SSRF ya parcheada mediante DNS rebinding. Por separado, un aviso de julio de 2026 para Langflow (el constructor visual de pipelines LLM) mostró que ciertos componentes de recuperación heredados hacían peticiones sin pasar por la protección SSRF añadida en una versión anterior. Productos distintos, mecanismos distintos, una misma lección: la frontera que decide si una petición está permitida debe ser exactamente la misma que abre el socket.

How it works

Ambos casos fallan de forma complementaria.

En mcp-atlassian, el parche añadió una comprobación validate_url_for_ssrf. Cuando una petición llevaba un host influido por el atacante en una cabecera X-Atlassian-*-Url, la guarda resolvía ese nombre una vez, verificaba que cada dirección devuelta fuera una IP pública (global) y devolvía un veredicto permitido/denegado. El problema está en lo que devolvía: un veredicto, no la IP que acababa de aprobar. El código que realiza la petición saliente se construía luego a partir del nombre de host en bruto y lo volvía a resolver en el momento de la conexión. Ese hueco entre la comprobación y el uso es una carrera clásica time-of-check to time-of-use (TOCTOU) (CWE-367). Un atacante que controla el DNS autoritativo de su dominio puede responder a la primera resolución con una IP pública (la guarda pasa) y a la segunda con una dirección interna (el socket se conecta allí). El resultado es una SSRF (CWE-918) sobre la versión parcheada.

# TOCTOU con DNS rebinding — por qué "validar y luego recuperar" no basta

  t0  guarda:  resolve(host) -> 93.184.216.34  (pública)   -> PASA, veredicto descartado
  t1  fetch:   resolve(host) -> 169.254.169.254 (metadatos) -> el socket conecta AQUÍ

  La comprobación y la conexión resolvieron el MISMO nombre a IP DISTINTAS.

El caso de Langflow es más simple y, en cierto modo, más común: la guarda existía, pero no todas las rutas pasaban por ella. Las protecciones SSRF introducidas en una versión anterior no cubrían algunos componentes de recuperación heredados (un lector RSS y un conector de metabúsqueda), que aún emitían peticiones a una URL suministrada por el usuario, directamente. Como esos componentes pueden ejecutarse en modo agéntico, la URL ni siquiera necesita venir de un operador humano: puede llegar por inyección de prompt indirecta en el contenido que el agente procesa. No se reproduce aquí ningún servidor de rebinding funcional ni payload; el punto es estructural, no una receta.

Why it matters

Ambos fallos viven en software cuyo trabajo entero es dejar que un modelo de lenguaje alcance el exterior: un servidor MCP que habla con Atlassian, un constructor de pipelines que recupera feeds y resultados de búsqueda. En ese contexto, el «usuario» que suministra una URL es con frecuencia el modelo, y las entradas del modelo pueden moldearse mediante un ticket, una página web o un documento que acaba de leer. Una primitiva SSRF aquí no es un bug de red abstracto: es una línea directa entre una entrada de agente no confiable y credenciales de metadatos en la nube y servicios internos, lo que se corresponde con los riesgos de herramientas e integraciones del OWASP LLM Top 10.

La razón más profunda es que ambas son historias de parche incompleto. Se registró un CVE, se publicó un parche, los paneles se pusieron en verde, y la protección seguía sin aguantar, porque la validación y la conexión no coincidían sobre qué dirección se contactaba realmente, o porque una segunda ruta de código nunca consultaba al validador. Es exactamente el tipo de regresión que se les escapa a las comprobaciones automáticas de «¿está parcheado?».

Defenses

Las mitigaciones duraderas para esta clase consisten en hacer que la decisión validada sea autoritativa hasta el socket:

1. Fijar la IP validada a la conexión. Haga que la comprobación SSRF devuelva la dirección concreta que aprobó, y luego fuerce la petición saliente a conectarse a esa IP (resolutor personalizado, getaddrinfo en caché o un adaptador que sobrescriba la resolución) preservando la cabecera Host original. Esto cierra la ventana de DNS rebinding porque no hay una segunda resolución que envenenar.
2. Un único punto de paso para toda la salida. Enrute cada petición saliente —incluidos los componentes heredados, opcionales y «de conveniencia»— a través del mismo cliente HTTP validado. Bugs como el de Langflow ocurren cuando una ruta lateral olvida que la guarda existe.
3. Bloquear los destinos sensibles en el momento de conectar, no solo al analizar. Deniegue los rangos link-local, loopback y privados (y la IP de metadatos) al abrir el socket, para que un nombre resuelto tardíamente no pueda colarse por una allowlist basada en nombres.
4. Tratar las URL suministradas por el agente como controladas por el atacante. Asuma que cualquier URL que reciba una herramienta pudo ser dirigida por contenido ingerido por el modelo; valide en la frontera de la herramienta como si viniera de un internauta anónimo.
5. Mínimo privilegio en el runtime. Prefiera IMDSv2 (o el equivalente en la nube) y limite estrechamente los roles de instancia, para que incluso una recuperación de metadatos exitosa rinda poco.

Status

Elemento	Referencia	Fecha	Notas
SSRF mcp-atlassian (cabecera)	CVE-2026-27826 / GHSA-7r34-79r5-rcc9	2026	SSRF X-Atlassian-*-Url original; parche que añade validate_url_for_ssrf
Elusión por rebinding	GHSA-489g-7rxv-6c8q	2026-07-10	Parche incompleto; TOCTOU (CWE-367) + SSRF (CWE-918); veredicto sin IP fijada; corregido en 0.22.0
SSRF Langflow	CVE-2026-10546	2026-07	Componentes de recuperación heredados que eluden la protección añadida en 1.9.3; alcanzable vía modo herramienta agéntico
Clase	OWASP LLM Top 10	2025	Diseño inseguro de herramientas/integraciones, agencia excesiva

Todos los detalles anteriores proceden de los avisos de los fabricantes y de registros CVE públicos; ambos problemas están divulgados. La lección trasciende estos dos productos: cualquier framework de agentes que recupere URL debe asumir que validar un nombre de host y luego volver a resolverlo —o dejar una segunda ruta de recuperación sin guarda— reabre exactamente el agujero que el parche pretendía cerrar.