CVE-2026-27826: SSRF no MCP Atlassian

A falha SSRF original da CVE-2026-27826, baseada em cabeçalhos, foi corrigida na versão 0.17.0. Falhas SSRF posteriores e distintas foram corrigidas na 0.22.0; confira cada aviso antes de definir a versão mínima da frota.^{[1], [2], [6], [8], [9], [10], [11]}

💡 Explicação em Linguagem Simples (ELI5)

Imagine uma sala de correspondência autorizada a entregar pacotes somente aos escritórios aprovados da empresa. Um visitante escreve outro destino em um formulário especial, e a equipe o aceita sem conferir. O fetcher do servidor é essa sala: os cabeçalhos da requisição indicavam o destino e o servidor fazia a chamada de saída. A correção da versão 0.17.0 confere a URL enviada antes da conexão e também verifica qualquer redirecionamento; o operador pode configurar uma lista de domínios permitidos como controle adicional.^{[1], [2]}

Conceitos Centrais e Termos

Server-side request forgery (SSRF): Falha que permite influenciar uma requisição de saída do servidor para alcançar um destino que a aplicação não pretendia contatar.^{[1], [4]}
Transporte MCP: Canal de comunicação entre um cliente e um servidor MCP. Esta falha afetava os transportes streamable-HTTP e SSE, não a implantação descrita no aviso que usa somente stdio.^[1]
Autenticação multi-tenant por cabeçalho: Modo que recebe URLs e tokens Atlassian em cada requisição para criar um cliente de API específico do locatário.^{[1], [2]}
Política de tráfego de saída: Controles de rede que limitam os destinos que um serviço pode contatar e reduzem o impacto de falhas na validação de URLs da aplicação.^{[12], [1]}
Injeção indireta de prompt: Conteúdo não confiável retornado por uma ferramenta pode conter instruções que influenciam um modelo. Neste CVE, o aviso descreve respostas controladas por terceiros entrando nos resultados da ferramenta; esse impacto é distinto da própria SSRF.^{[1], [7]}
Correções posteriores de SSRF: O aviso original da CVE-2026-27826 indica a versão 0.17.0 como corrigida. Depois, a mantenedora documentou quatro caminhos distintos de correção incompleta como CVE-2026-77242, CVE-2026-77267, CVE-2026-77249 e CVE-2026-77274; cada aviso lista a 0.22.0 como corrigida. São CVEs separadas, não uma ampliação do intervalo afetado pela CVE-2026-27826. Confira avisos posteriores antes de escolher a versão mínima para toda a frota.^{[8], [9], [10], [11]}

Mapeamentos de frameworks

Referência CWE para a fraqueza descrita neste guia: CWE-918
OWASP GenAI 2025 — LLM01:2025 Injeção de prompt
D3-OTF Filtragem de tráfego de saída — A restrição de rede de saída deste guia limita os destinos que o serviço ou host pode alcançar.

Análise de Causa Raiz

No fluxo HTTP afetado, o servidor extraía X-Atlassian-Jira-Url ou X-Atlassian-Confluence-Url da requisição e passava o valor a uma JiraConfig ou ConfluenceConfig usada para criar um fetcher. No ramo vulnerável de autenticação por cabeçalho, o destino não era comparado com a URL do locatário configurada pelo servidor nem com uma política de destinos antes da primeira chamada do fetcher. O aviso do mantenedor identifica o middleware de requisição e o provedor de dependências, não um manipulador individual de ferramenta MCP. A falha exige o transporte HTTP afetado e as condições de autenticação por cabeçalho; não a generalize para toda implantação MCP.^{[1], [2]}

Fluxo de Ataque Passo a Paso

Passo 1

Transporte HTTP acessível

A implantação usa o transporte streamable-HTTP ou SSE e expõe o endpoint MCP a um solicitante que consegue alcançá-lo.^{[1], [2]}

Passo 2

Cabeçalhos escolhem a URL do serviço

No fluxo afetado de autenticação por cabeçalho, os cabeçalhos de URL e token Jira ou Confluence estão presentes sem o cabeçalho Authorization esperado pelo fluxo alternativo.^{[1], [2]}

Passo 3

O middleware cria o fetcher

O middleware guarda a URL recebida, e o provedor de dependências a usa para configurar um fetcher Atlassian sem impor a fronteira de destino pretendida.^{[1], [2]}

Passo 4

O servidor faz a chamada de saída

A inicialização do fetcher envia uma requisição ao destino escolhido pelo solicitante. Conforme a rede e a resposta do destino, isso pode expor serviços internos ou inserir conteúdo controlado por terceiros nos resultados da ferramenta.^{[1], [2]}

Código-Fonte: Vulnerável vs. Seguro

O trecho vulnerável permite que uma URL de cabeçalho escolha o destino de saída do servidor. O patch upstream 0.17.0 não substitui esse modo de locatário por cabeçalho por um cadastro de locatários no servidor: ele valida a URL Jira ou Confluence fornecida no middleware ASGI antes de criar o fetcher e depois adiciona um hook de resposta para validar os destinos de redirecionamento. O trecho protegido mostra esses dois controles upstream; a implementação do validador foi omitida. Um cadastro de locatários no servidor é uma arquitetura alternativa mais forte, não o que esse patch implementa. Os avisos posteriores da 0.22.0 documentam caminhos residuais distintos; portanto, não trate a 0.17.0 como versão mínima para toda a frota sem analisá-los. A validação DNS também precisa ser aplicada no momento da conexão para resistir a rebinding; uma única consulta do hostname não completa a proteção contra SSRF.^{[1], [2]}

Trecho de origem: Trecho do patch upstream no middleware e no fetcher (fluxo Jira; Confluence tem a proteção equivalente).

IMPLEMENTAÇÃO VULNERÁVEL

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

PATCH SEGURO E 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 Verificação de Segurança para Engenharia

✓Não aceite URLs base de locatário em cabeçalhos controlados pelo solicitante ou sem autenticação; identifique o locatário pela identidade autenticada e pela configuração do servidor.^{[1], [2]}
✓Permita somente nomes HTTPS Atlassian provisionados explicitamente para cada locatário; rejeite userinfo, portas inesperadas e formatos ambíguos de URL.^{[1], [8], [9], [10], [11]}
✓Aplique a política de destino a redirecionamentos e ao destino real da conexão, não apenas à URL inicialmente analisada.^{[2], [8]}
✓Restrinja a rede de saída dos serviços MCP para impedir acesso a loopback, endereços privados, link-local e metadados, salvo necessidade aprovada.^{[12], [1]}
✓Trate todos os resultados de ferramentas como conteúdo não confiável; texto recuperado do Jira ou Confluence não pode ampliar permissões nem autorizar ações.^{[1], [7]}
✓Audite cada caminho que cria JiraFetcher ou ConfluenceFetcher, inclusive funções auxiliares que possam usar uma sessão HTTP separada.^{[2], [8], [9], [10], [11]}
✓Atualize para uma versão posterior a 0.17.0 para corrigir este CVE e verifique os avisos atuais do mantenedor sobre SSRF registrados separadamente antes de definir a versão mínima da frota.^{[1], [6], [8], [9], [10], [11]}
✓Mantenha as decisões de versão separadas: 0.17.0 corrige o caminho original da CVE-2026-27826; os quatro avisos SSRF posteriores (CVE-2026-77242, CVE-2026-77267, CVE-2026-77249 e CVE-2026-77274) listam a 0.22.0 como corrigida. Confira a lista atual de avisos para identificar novas falhas antes de definir a versão mínima da frota.^{[6], [8], [9], [10], [11]}