CVE-2026-32941: 
vulnerability analysis and mitigation

CVE-2026-32941 is a Remote Out-of-Memory (OOM) vulnerability in the Sliver C2 framework's mTLS and WireGuard transport layer, allowing authenticated attackers to crash the server via memory exhaustion. It affects BishopFox Sliver versions 1.7.3 and below. The vulnerability was published on March 20, 2026, and as of the advisory's publication, no patched version had been released. It carries a CVSS v3.1 base score of 6.5 (Medium) and a CVSS v4.0 base score of 5.7 (Medium) (GitHub Advisory, Feedly).

The root cause is classified under CWE-770 (Allocation of Resources Without Limits or Throttling) and CWE-789 (Memory Allocation with Excessive Size Value). The socketReadEnvelope and socketWGReadEnvelope functions read a 4-byte little-endian length prefix from the wire and immediately allocate a buffer of that size — up to ServerMaxMessageSize of ~2 GiB — before performing any per-envelope ed25519 signature verification. An attacker who has completed a valid TLS handshake (using a valid implant certificate or compromised credentials) can open up to 128 concurrent yamux streams per connection and send a fabricated 4-byte prefix of 0x7FFFFFFF on each stream, triggering 128 parallel ~2 GiB allocations (~256 GiB total) and causing the OS OOM killer to terminate the server process. Implant-side readers are additionally affected with no upper-bound check whatsoever (GitHub Advisory).

Successful exploitation crashes the Sliver C2 server process, immediately disrupting all active implant sessions and requiring manual operator intervention to restart. On hosts with swap enabled, the OOM event may cause swap thrashing that degrades or kills other co-hosted processes before the Sliver process is terminated. There is no confidentiality or integrity impact — the vulnerability is a pure availability (Denial of Service) issue that can be weaponized by a compromised implant or any operator-level credential holder to neutralize an entire red team or threat actor's C2 infrastructure (GitHub Advisory).

1. Obtain valid credentials: Acquire a valid Sliver implant client certificate or operator credentials that allow establishing an mTLS connection to the target Sliver C2 server.
2. Establish mTLS connection: Complete a valid TLS 1.3 handshake with the Sliver server using the implant certificate, satisfying the transport-layer authentication check.
3. Negotiate yamux multiplexing: Send the MUX/1 preface over the established TLS connection to enter multiplexed stream mode.
4. Open concurrent yamux streams: Open up to 128 concurrent yamux streams on the single connection (the maximum allowed by mtlsYamuxMaxConcurrentStreams).
5. Send malicious length prefix: On each stream, transmit a 74-byte raw signature buffer followed by a 4-byte little-endian length prefix set to 0x7FFFFFFF (2,147,483,647 bytes ≈ 2 GiB). No actual protobuf data payload needs to follow.
6. Trigger OOM kill: Each stream causes the server to execute make([]byte, 0x7FFFFFFF), attempting ~256 GiB of total allocation across 128 streams, causing the OS OOM killer to terminate the Sliver server process and disrupt all active implant sessions. This can be executed using the public mtls_poc.go tool with go run mtls_poc.go (GitHub Advisory, PoC Repo).

• Logs: Sudden termination of the Sliver server process with no graceful shutdown log entry; OS-level OOM killer log entries (e.g., kernel: Out of memory: Kill process <pid> (sliver-server) in /var/log/kern.log or dmesg).
• Network: High volume of concurrent mTLS or WireGuard connections from a single source IP to the Sliver C2 listener port; yamux stream negotiation (MUX/1 preface) followed by rapid opening of 128 streams with minimal data transfer.
• Process: Sliver server process memory usage spiking rapidly to near-system-memory limits before process termination; unexpected restart of the sliver-server process by a watchdog or operator.
• File System: Core dump files generated in the Sliver server working directory following an OOM kill event (GitHub Advisory).

As of the advisory's publication date, no patched version of Sliver had been released (all versions ≤ 1.7.3 are affected). Operators should restrict network access to the Sliver C2 server to trusted operator IPs only using firewall rules or network segmentation, reducing the attack surface to only authorized personnel. Monitor the Sliver server host for unusual memory consumption patterns and configure alerting on OOM events. Enforce strict limits on message length prefixes at the transport layer as a code-level workaround if operating a custom build. Check the GitHub Advisory for updates on patch availability.

The vulnerability was reported by researcher skoveit, who also published the public PoC exploit code on GitHub. The advisory was published by BishopFox's moloch-- on March 16, 2026. The openSUSE security announce mailing list referenced the issue in April 2026, and it was picked up by Linux security advisory aggregators (openSUSE). Community reaction has been moderate given Sliver's primary use as a red team/adversary simulation tool, with the main concern being that a compromised implant or rogue operator could neutralize an entire C2 infrastructure.