Hewei-Gikaku

A função `upload attachment()` nos módulos Jira e Confluence não restringe o caminho resolvido ao espaço de trabalho do servidor, permitindo o uso de caminhos absolutos e sequências de travessia (traversal). Isso ocorre porque a função não chama `validate safe path()`, permitindo que um chamador MCP autenticado com acesso a anexos leia arquivos locais arbitrários do servidor (como `/etc/passwd` ou `/proc/self/environ`) e os exfiltre, enviando-os como anexos para uma instância do Jira ou Confluence. O problema afeta a função `upload attachment()` em `src/mcp atlassian/jira/attachments.py` e `src/mcp atlassian/confluence/attachments.py`, bem como a função ` upload attachment direct()` em `src/mcp atlassian/confluence/attachments.py`. O parâmetro vulnerável é `file path`.

Quando a autenticação do registro é ativada por meio da variável `OBOT SERVER ENABLE REGISTRY AUTH`, o software falha ao aplicar a autenticação nos endpoints do MCP Registry sob o caminho `/v0.1/*`. Isso ocorre porque o autorizador utiliza um conjunto fixo de prefixos protegidos e permite por padrão os demais; como o prefixo `/v0.1` não estava nesse conjunto, requisições anônimas eram autorizadas antes de atingirem o desafio de autenticação. Atacantes não autenticados podem enviar requisições GET para o endpoint `/v0.1/servers` para ler metadados do registro, incluindo nomes de servidores, descrições, URLs de repositório e URLs de conexão. Este problema não expõe valores de credenciais, e usuários não autenticados não podem se conectar aos servidores, pois o processo de conexão permanece protegido.

O Obot contém um problema de server-side request forgery (SSRF) durante o registro de servidores MCP remotos. Usuários privilegiados com as funções de Power User, Power User Plus ou Admin podem especificar URLs arbitrárias na variável `RemoteRuntimeConfig.URL` sem validação de destino. O sistema não bloqueia requisições para loopback, endereços link-local, intervalos privados RFC1918 ou o endpoint de metadados da nuvem (`169.254.169.254`). Consequentemente, um invasor pode coagir o servidor a fazer requisições a serviços internos e ao serviço de metadados da instância na nuvem, lendo as respostas por meio de mensagens de erro para expor informações sensíveis, como credenciais de IAM da nuvem.

Ao operar no modo HTTP com o `--lockdown-mode` ativado, o `RepoAccessCache` é implementado como um singleton global do processo. Este singleton é inicializado usando o cliente GraphQL do primeiro usuário autenticado, e solicitações subsequentes de diferentes usuários continuam a usar a mesma instância. Consequentemente, as consultas GraphQL relacionadas ao lockdown são executadas usando as credenciais do primeiro usuário, em vez do token do solicitante atual. Este problema afeta a função `GetInstance()` em `pkg/lockdown/lockdown.go`, que não atualiza o cliente interno quando chamada por diferentes usuários. Isso leva a resultados incorretos na função `IsSafeContent()`, que depende de `queryRepoAccessInfo` para determinar se o conteúdo de contribuidores externos deve ser confiado ou sanitizado. Os impactos potenciais incluem verificações de visibilidade de repositório incorretas, acesso não autorizado a dados em cache com base nas permissões do primeiro usuário e a falha total da proteção de lockdown se o token do primeiro usuário expirar.