Skoveit

**Nome do Software Vulnerável e Versões Afetadas** Nhost versões anteriores a 0.49.1 **Descrição** O Nhost vincula automaticamente identidades OAuth recebidas a contas existentes quando os endereços de e-mail coincidem, desde que o e-mail seja marcado como verificado. Vários adaptadores de provedores não preenchem corretamente o booleano `profile.EmailVerified`, levando a um possível sequestro de conta. Especificamente, o adaptador do Discord ignora o campo `verified` da API, e o adaptador do Bitbucket recorre ao uso de e-mails não confirmados, marcando-os como verificados. Além disso, os adaptadores AzureAD e EntraID derivam e-mails de campos que não comprovam a propriedade, como o nome principal do usuário, e os marcam como verificados independentemente da propriedade real. Isso permite que um invasor use um e-mail que não possui para fundir sua identidade OAuth com a conta de uma vítima e obtenha uma sessão autenticada completa. Detalhes técnicos incluem o seguinte: - **Função Vulnerável**: `providerFlowSignIn()` em `services/auth/go/controller/sign in id token.go` vincula identidades sem uma guarda de verificação. - **Variáveis Vulneráveis**: O booleano `profile.EmailVerified` é confiado ou preenchido incorretamente. **Recomendações** Atualize para a versão 0.49.1. Como medida paliativa temporária, restrinja o uso do Discord, Bitbucket, AzureAD e EntraID como provedores OAuth até que a atualização seja aplicada.

**Name of the Vulnerable Software and Affected Versions** Nhost versions prior to 1.41.0 **Description** Nhost is an open source Firebase alternative with GraphQL. The Nhost CLI MCP server, when explicitly configured to listen on a network port, does not apply inbound authentication and does not enforce strict CORS. This allows a malicious website visited on the same machine to issue cross-origin requests to the MCP server and invoke privileged tools using the developer's locally configured credentials. This requires two explicit, non-default configuration steps to be exploitable. The default nhost mcp start configuration is not affected. **Recommendations** Update to version 1.41.0 or later.

**Name of the Vulnerable Software and Affected Versions** Sliver versions prior to 1.7.4 **Description** Sliver is a command and control framework that utilizes a custom Wireguard netstack. Prior to version 1.7.4, an unauthenticated attacker can gain immediate, silent control over all active C2 sessions or beacons with a single click on a malicious link. This allows for the exfiltration of collected target data, such as SSH keys and `ntds.dit`, or the destruction of the entire compromised infrastructure, all through the operator's browser. The Sliver MCP server, running within the Sliver Client, binds to `localhost:8080` by default with a permissive `Access-Control-Allow-Origin: *` header. This allows cross-origin requests from any arbitrary website to interact with the MCP interface via an operator's browser without credentials. If the interface is misconfigured to bind to all interfaces (`0.0.0.0`), the vulnerability escalates to direct, unauthenticated remote access. Exploitation grants access to methods like `list sessions and beacons`, `fs ls`, `fs pwd`, `fs cd`, `fs cat`, `fs rm`, `fs mv`, `fs cp`, `fs mkdir`, `fs chmod`, and `fs chown`. The root cause is an insecure integration with the `mcp-go` library, which fails to validate the `Content-Type` header, allowing attackers to bypass CORS preflight checks. The Sliver implementation also lacks authentication middleware or origin restrictions. **Recommendations** Versions prior to 1.7.4 should be updated to version 1.7.4 or later.

**Name of the Vulnerable Software and Affected Versions** Sliver versions 1.7.3 and below **Description** Sliver is a command and control framework that utilizes a custom Wireguard network stack. Versions 1.7.3 and below contain a Remote Out-of-Memory (OOM) issue in the mTLS and WireGuard C2 transport layer of the Sliver C2 server. The `socketReadEnvelope` and `socketWGReadEnvelope` functions rely on an attacker-controlled 4-byte length prefix to allocate memory, with `ServerMaxMessageSize` allowing single allocations of up to approximately 2 GiB. A compromised implant or an attacker with valid credentials can exploit this by sending fabricated length prefixes over concurrent yamux streams (up to 128 per connection), forcing the server to attempt allocating approximately 256 GiB of memory and triggering an OS OOM kill. This crashes the Sliver server, disrupts all active implant sessions, and may degrade or kill other processes sharing the same host. The same pattern also affects all implant-side readers, which lack any upper-bound check. The issue was not resolved at the time of publication. **Recommendations** Versions prior to 1.7.4 are vulnerable. At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Nome do Software Vulnerável e Versões Afetadas** Versões do Sliver anteriores à correção **Descrição** Sliver, um servidor C2, contém uma falta sistêmica de validação de ponteiros nulos em sua lógica de desserialização Protobuf. Isso permite que um ator autenticado, ao omitir campos aninhados em uma mensagem assinada, dispare um panic de tempo de execução não tratado. As camadas de transporte mTLS, WireGuard e DNS não possuem o middleware de recuperação de panic presente no transporte HTTP, resultando na terminação global do processo. Isso age efetivamente como um interruptor de emergência da infraestrutura, interrompendo instantaneamente todas as sessões ativas e exigindo uma reinicialização manual do servidor. A vulnerabilidade decorre do tratamento arquitetural de mensagens Protobuf, onde submensagens aninhadas omitidas resultam em ponteiros nulos. Acessar propriedades desses ponteiros nulos dispara o panic. Vários manipuladores em diferentes componentes, incluindo registro de beacon, tunelamento reverso, proxy SOCKS e funções RPC, são suscetíveis. O impacto dessa vulnerabilidade é a paralisação operacional total, já que causa uma falha completa do servidor, levando à desconexão global das sessões, riscos potenciais de persistência e expulsão do operador. A vulnerabilidade pode ser explorada mediante a extração de credenciais válidas do implant, que geralmente estão prontamente disponíveis em ambientes comprometidos. **Recomendações** Implemente validação estrita para todos os campos aninhados do Protobuf para garantir que os manipuladores não tentem dereferenciar ponteiros nulos. Descontinue o acesso direto ao campo de metadados da Request na interface gRPC e utilize acessores seguros que lidem com metadados ausentes de forma robusta. Implemente um padrão supervisor utilizando o mecanismo recover() do Go em todos os transportes multiplexados (mTLS, WireGuard, DNS) para capturar panics de tempo de execução e evitar falhas do servidor. Adote a validação automatizada de esquemas utilizando ferramentas como protoc-gen-validate para aplicar campos obrigatórios e gerar código de validação.