Skoveit

**Name of the Vulnerable Software and Affected Versions** Nhost versions prior to 0.49.1 **Description** Nhost automatically links incoming OAuth identities to existing accounts when email addresses match, provided the email is marked as verified. Several provider adapters fail to correctly populate the `profile.EmailVerified` boolean, leading to potential account takeover. Specifically, the Discord adapter ignores the `verified` field from the API, and the Bitbucket adapter falls back to using unconfirmed emails while marking them as verified. Additionally, the AzureAD and EntraID adapters derive emails from non-ownership-proving fields, such as the user principal name, and mark them as verified regardless of actual ownership. This allows an attacker to use an email they do not own to merge their OAuth identity into a victim's account and obtain a full authenticated session. Technical details include the following: - **Vulnerable Function**: `providerFlowSignIn()` in `services/auth/go/controller/sign in id token.go` links identities without a verification guard. - **Vulnerable Variables**: The `profile.EmailVerified` boolean is incorrectly trusted or populated. **Recommendations** Update to version 0.49.1. As a temporary workaround, restrict the use of Discord, Bitbucket, AzureAD, and EntraID as OAuth providers until the update is applied.

**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.

**Name of the Vulnerable Software and Affected Versions** Sliver versions prior to the fix **Description** Sliver, a C2 server, contains a systemic lack of nil-pointer validation in its Protobuf unmarshalling logic. This allows an authenticated actor, by omitting nested fields in a signed message, to trigger an unhandled runtime panic. The mTLS, WireGuard, and DNS transport layers lack the panic recovery middleware present in the HTTP transport, resulting in a global process termination. This effectively acts as an infrastructure "kill-switch," instantly severing all active sessions and requiring a manual server restart. The vulnerability stems from the architectural handling of Protobuf messages, where omitted nested sub-messages result in nil pointers. Accessing properties of these nil pointers triggers the panic. Multiple handlers across various components, including beacon registration, reverse tunneling, SOCKS proxying, and RPC functions, are susceptible. The impact of this vulnerability is total operational paralysis, as it causes a complete server crash, leading to global disconnection of sessions, potential persistence risks, and operator eviction. The vulnerability can be exploited by extracting valid implant credentials, which are often readily available in compromised environments. **Recommendations** Implement strict validation for all nested Protobuf fields to ensure that handlers do not attempt to dereference nil pointers. Deprecate direct access to the Request metadata field in the gRPC interface and use safe accessors that handle missing metadata gracefully. Implement a supervisor pattern using Go's recover() mechanism in all multiplexed transports (mTLS, WireGuard, DNS) to catch runtime panics and prevent server crashes. Move towards automated schema validation using tools like protoc-gen-validate to enforce required fields and generate validation code.