Most recent entries from all

EUVD-2026-276798

2026-10-06T05:53:16.368667+00:00

EUVD-2026-276798

fkie_cve-2026-32941

2026-10-06T05:53:16.368704+00:00

Sliver is a command and control framework that uses a custom Wireguard netstack. Versions 1.7.3 and below contain a Remote OOM (Out-of-Memory) vulnerability in the Sliver C2 server's mTLS and WireGuard C2 transport layer. The socketReadEnvelope and socketWGReadEnvelope functions trust an attacker-controlled 4-byte length prefix to allocate memory, with ServerMaxMessageSize allowing single allocations of up to ~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 ~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 have no upper-bound check at all. The issue was not fixed at the the time of publication.

GHSA-97vp-pwqj-46qc — Sliver Vulnerable to Authenticated OOM via Memory Exhaustion in mTLS/WireGuard Transports

2026-10-06T05:53:16.368745+00:00

Affected: Go: github.com/bishopfox/sliver

# Summary A Remote OOM (Out-of-Memory) vulnerability exists in the Sliver C2 server's mTLS and WireGuard C2 transport layer. The `socketReadEnvelope` and `socketWGReadEnvelope` functions trust an attacker-controlled 4-byte length prefix to allocate memory, with `ServerMaxMessageSize` allowing single allocations of up to **~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 **~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 have **no** upper-bound check at all.

--- # Root Cause Analysis

The C2 envelope framing protocol uses a 4-byte little-endian length prefix to delimit protobuf messages on the wire:

``` [raw_signature (74 bytes)] [uint32 length] [protobuf data] ```

In [socketReadEnvelope](https://github.com/BishopFox/sliver/blob/master/server/c2/mtls.go#L337-L392), after reading the length prefix, the server immediately allocates a buffer of the attacker-specified size:

```go // server/c2/mtls.go const ServerMaxMessageSize = (2 * 1024 * 1024 * 1024) - 1 // ~2 GiB

dataLength := int(binary.LittleEndian.Uint32(dataLengthBuf)) if dataLength <= 0 || ServerMaxMessageSize < dataLength { return nil, errors.N…