CVE-2026-27826: SSRF en MCP Atlassian

La SSRF original de CVE-2026-27826, basada en encabezados, se corrigió en 0.17.0. Otras fallas SSRF distintas se corrigieron en 0.22.0; revisa cada aviso antes de fijar la versión mínima de toda la flota.^{[1], [2], [6], [8], [9], [10], [11]}

💡 Explicación en Lenguaje Sencillo (ELI5)

Imagina una oficina de correos autorizada a entregar paquetes solo en las sedes aprobadas de una empresa. Un visitante escribe otro destino en un formulario especial y el personal lo acepta sin comprobarlo. El fetcher del servidor es esa oficina: las cabeceras indicaban el destino y el servidor realizaba la petición saliente. La corrección de 0.17.0 comprueba la URL enviada antes de conectarse y también revisa cualquier redirección; el operador puede configurar además una lista de dominios permitidos.^{[1], [2]}

Conceptos Clave y Términos

Server-side request forgery (SSRF): Fallo que permite influir en una petición saliente del servidor para que llegue a un destino que la aplicación no pretendía contactar.^{[1], [4]}
Transporte MCP: Canal de comunicación entre un cliente y un servidor MCP. Este fallo afectaba a los transportes streamable-HTTP y SSE, no a la implementación descrita en el aviso que solo usa stdio.^[1]
Autenticación multi-tenant mediante cabeceras: Modo que recibe URL y tokens Atlassian en cada petición para crear un cliente de API específico del tenant.^{[1], [2]}
Política de salida de red: Controles que limitan los destinos a los que puede conectarse un servicio y reducen el impacto de errores de validación de URL en la aplicación.^{[12], [1]}
Inyección indirecta de prompts: El contenido no confiable devuelto por una herramienta puede incluir instrucciones que influyan en el modelo. En este CVE, el aviso describe respuestas controladas por terceros que entran en resultados de herramientas; es un impacto distinto de la SSRF.^{[1], [7]}
Correcciones posteriores de SSRF: El aviso original de CVE-2026-27826 indica que 0.17.0 la corrige. Después, el mantenedor documentó cuatro rutas de corrección incompleta distintas como CVE-2026-77242, CVE-2026-77267, CVE-2026-77249 y CVE-2026-77274; cada aviso indica 0.22.0 como versión corregida. Son CVE diferentes, no una ampliación del rango afectado de CVE-2026-27826. Revisa los avisos posteriores antes de elegir una versión mínima para toda la flota.^{[8], [9], [10], [11]}

Mapeos de marcos

Referencia CWE para la debilidad descrita en esta guía: CWE-918
OWASP GenAI 2025 — LLM01:2025 Inyección de prompts
D3-OTF Filtrado del tráfico saliente — La restricción de red saliente de esta guía limita los destinos a los que puede acceder el servicio o el host.

Análisis de Causa Raíz

En la ruta HTTP afectada, el servidor extraía X-Atlassian-Jira-Url o X-Atlassian-Confluence-Url de la petición y pasaba ese valor a una JiraConfig o ConfluenceConfig utilizada para crear un fetcher. En la rama vulnerable de autenticación por cabeceras, el destino no se contrastaba con la URL del tenant configurada por el servidor ni con una política de destinos antes de la primera petición del fetcher. El aviso del mantenedor señala el middleware de peticiones y el proveedor de dependencias, no un controlador concreto de herramientas MCP. El fallo requiere el transporte HTTP afectado y las condiciones de autenticación por cabeceras; no debe generalizarse a todas las implementaciones MCP.^{[1], [2]}

Flujo de Ataque Paso a Paso

Paso 1

Transporte HTTP accesible

La implementación usa streamable-HTTP o SSE y expone el endpoint MCP a quien pueda alcanzarlo.^{[1], [2]}

Paso 2

Las cabeceras seleccionan la URL del servicio

En la ruta afectada de autenticación por cabeceras, están presentes las cabeceras de URL y token de Jira o Confluence sin la cabecera Authorization esperada por la ruta alternativa.^{[1], [2]}

Paso 3

El middleware crea el fetcher

El middleware guarda la URL recibida y el proveedor de dependencias la usa para configurar un fetcher Atlassian sin imponer el límite de destino previsto.^{[1], [2]}

Paso 4

El servidor realiza una petición saliente

La inicialización del fetcher envía una petición al destino elegido por quien llama. Según la red y la respuesta, esto puede exponer servicios internos o introducir contenido controlado por terceros en los resultados de las herramientas.^{[1], [2]}

Código Fuente: Vulnerable vs. Seguro

El fragmento vulnerable permite que una URL de una cabecera elija el destino saliente del servidor. El parche upstream 0.17.0 no sustituye ese modo de tenant mediante cabeceras por un registro de tenants del servidor: valida la URL de Jira o Confluence recibida en el middleware ASGI antes de crear el fetcher y después añade un hook de respuesta para validar los destinos de redirección. El fragmento protegido muestra esos dos controles upstream; omite la implementación del validador. Un registro de tenants del servidor es una arquitectura alternativa más sólida, no lo que implementa este parche. Los avisos posteriores de 0.22.0 documentan rutas residuales distintas; no tomes 0.17.0 como versión mínima para toda la flota sin revisarlos. La validación DNS también debe aplicarse en el momento de la conexión para resistir el rebinding; una sola consulta del nombre no completa la defensa contra SSRF.^{[1], [2]}

Fragmento de origen: Fragmento del parche upstream en middleware y fetcher (ruta de Jira; Confluence tiene la protección equivalente).

IMPLEMENTACIÓN VULNERABLE

header_jira_fetcher = JiraFetcher(config=header_config)
current_user_id = header_jira_fetcher.get_current_user_account_id()

PARCHE SEGURO Y ROBUSTO

ssrf_error = validate_url_for_ssrf(jira_url_str)
if ssrf_error:
    scope["state"]["auth_validation_error"] = (
        f"Forbidden: Invalid Jira URL - {ssrf_error}"
    )
    return

header_jira_fetcher = JiraFetcher(config=header_config)
header_jira_fetcher.jira._session.hooks["response"].append(
    _make_ssrf_safe_hook(validate_url_for_ssrf)
)
current_user_id = header_jira_fetcher.get_current_user_account_id()

Lista de Verificación de Seguridad para Ingeniería

✓No aceptes URL base de tenant desde cabeceras controladas por quien llama o sin autenticar; identifica el tenant mediante identidad autenticada y configuración del servidor.^{[1], [2]}
✓Permite solo nombres HTTPS de Atlassian aprovisionados explícitamente para cada tenant; rechaza userinfo, puertos inesperados y URL ambiguas.^{[1], [8], [9], [10], [11]}
✓Aplica la política de destino a las redirecciones y al destino real de la conexión, no solo a la URL analizada inicialmente.^{[2], [8]}
✓Restringe la red saliente de los servicios MCP para impedir el acceso a loopback, direcciones privadas, link-local y metadatos salvo que se autorice expresamente.^{[12], [1]}
✓Trata todos los resultados de herramientas como contenido no confiable; el texto recuperado de Jira o Confluence no debe ampliar permisos ni autorizar acciones.^{[1], [7]}
✓Audita todas las rutas que crean JiraFetcher o ConfluenceFetcher, incluidas funciones auxiliares que puedan usar una sesión HTTP distinta.^{[2], [8], [9], [10], [11]}
✓Actualiza a una versión posterior a 0.17.0 para corregir este CVE y revisa los avisos actuales del mantenedor sobre hallazgos SSRF separados antes de fijar la versión mínima de toda la flota.^{[1], [6], [8], [9], [10], [11]}
✓Mantén separadas las decisiones de versión: 0.17.0 corrige la ruta original de CVE-2026-27826; los cuatro avisos SSRF posteriores (CVE-2026-77242, CVE-2026-77267, CVE-2026-77249 y CVE-2026-77274) indican 0.22.0 como corregida. Revisa la lista vigente de avisos por si hay fallos posteriores antes de fijar una versión mínima para toda la flota.^{[6], [8], [9], [10], [11]}