Dodge1218

Nocturne Memory is a lightweight, rollbackable, and visual Long-Term Memory Server for MCP Agents. Prior to 2.4.1, when API TOKEN is unset or empty, the BearerTokenAuthMiddleware bypasses authentication for all HTTP requests. Combined with the default 0.0.0.0 host binding and CORS allow origins=["*"], operators following the Docker setup without explicitly setting API TOKEN expose the full Knowledge-Graph read/write API to any LAN-reachable client. An attacker on the same network can read, write, or delete all memory entries — including system://boot and core://* URIs that auto-load into downstream agent sessions, enabling persistent prompt-injection. This vulnerability is fixed in 2.4.1.

**Nome do Software Vulnerável e Versões Afetadas** Windows-MCP versões anteriores a 0.7.5 **Description** Nos modos de transporte SSE e Streamable HTTP, o plano de controle MCP é exposto sem autenticação e utiliza CORS (Cross-Origin Resource Sharing) com curinga, o que permite qualquer origem, método ou cabeçalho. Essa configuração permite que origens arbitrárias ou clientes que não sejam navegadores acessem o plano de controle. Como o servidor também expõe uma ferramenta `PowerShell` que executa comandos controlados pelo chamador através da variável `command` como o usuário do Windows que executa a aplicação, um invasor pode conseguir a execução arbitrária de comandos PowerShell. O problema decorre da função ` http middleware()` instalar o `CORSMiddleware` com políticas de curinga e a função ` build mcp()` construir a instância sem um provedor de autenticação. A falha é acionada especificamente ao usar o endpoint '/mcp' para inicializar uma sessão e invocar a função `tools/call` para a ferramenta `PowerShell`. **Recommendations** Atualize para a versão 0.7.5. Como medida paliativa temporária, evite usar os modos de transporte SSE e Streamable HTTP e utilize, em vez disso, o modo stdio padrão.

**Nome do Software Vulnerável e Versões Afetadas** Gryph versões anteriores a 0.7.0 **Description** O Gryph implementa níveis de log para controlar o conteúdo armazenado em um banco de dados sqlite local. O nível de log padrão está definido como `standard`, embora a documentação indique incorretamente que seja `minimal`. Nos níveis de log `standard` e `full`, conteúdos sensíveis de `file-write` são mantidos no `payload` armazenado através das variáveis `ContentPreview`, `OldString` ou `NewString`. Isso resulta no registro de conteúdo de arquivos potencialmente sensíveis, ignorando o filtro de arquivos sensíveis e os contratos de nível de log. Este problema pode levar à exposição de dados sensíveis caso o banco de dados sqlite local seja roubado ou exportado para um sistema remoto. **Recommendations** Atualize para a versão 0.7.0.