CVE-2026-32941 Overview
CVE-2026-32941 is a Remote Out-of-Memory (OOM) Denial of Service vulnerability affecting the Sliver Command and Control (C2) framework developed by BishopFox. The vulnerability exists in the mTLS and WireGuard C2 transport layers, where the socketReadEnvelope and socketWGReadEnvelope functions improperly trust an attacker-controlled 4-byte length prefix when allocating memory. This allows an attacker with valid credentials or a compromised implant to crash the Sliver server by forcing massive memory allocations.
Critical Impact
An attacker can trigger an OS OOM kill by sending fabricated length prefixes over concurrent yamux streams, forcing the server to attempt allocating approximately 256 GiB of memory. This crashes the Sliver server, disrupts all active implant sessions, and may degrade or kill other processes on the same host.
Affected Products
- BishopFox Sliver versions 1.7.3 and below
- Sliver C2 mTLS transport layer
- Sliver C2 WireGuard transport layer
Discovery Timeline
- 2026-03-20 - CVE-2026-32941 published to NVD
- 2026-03-24 - Last updated in NVD database
Technical Details for CVE-2026-32941
Vulnerability Analysis
The vulnerability stems from improper allocation of resources without limits or throttling (CWE-770). The Sliver C2 server's message handling functions trust client-provided length values when allocating memory buffers. The ServerMaxMessageSize configuration allows single allocations of up to approximately 2 GiB. An attacker can exploit the yamux multiplexing protocol, which permits up to 128 concurrent streams per connection, to amplify the attack impact.
When a malicious actor sends fabricated length prefixes across multiple concurrent yamux streams, the server attempts to allocate memory for each request without proper validation. With 128 streams each requesting ~2 GiB allocations, the total memory demand can reach approximately 256 GiB, far exceeding typical server memory capacity and triggering the operating system's OOM killer.
The vulnerability also affects all implant-side readers, which lack any upper-bound check on allocation sizes, making implants equally vulnerable to similar attacks from a malicious C2 server or man-in-the-middle attacker.
Root Cause
The root cause is the absence of proper input validation on the 4-byte length prefix used in the socketReadEnvelope and socketWGReadEnvelope functions. These functions directly use the attacker-controlled length value to allocate memory without enforcing reasonable upper bounds or implementing resource throttling mechanisms. This design flaw allows attackers to request arbitrarily large memory allocations.
Attack Vector
The attack vector is network-based, requiring the attacker to have valid credentials or control of a compromised implant. The attacker establishes a connection to the Sliver C2 server using either mTLS or WireGuard transport protocols. Once connected, the attacker opens multiple yamux streams (up to 128 per connection) and sends packets with maliciously crafted length prefixes indicating extremely large payload sizes. The server trusts these values and attempts to allocate the requested memory, leading to resource exhaustion and an OOM condition.
The vulnerability requires low privileges (valid credentials or compromised implant access) but no user interaction, making it relatively straightforward to exploit in scenarios where an attacker has gained initial access to the C2 infrastructure.
Detection Methods for CVE-2026-32941
Indicators of Compromise
- Sudden termination of the Sliver C2 server process due to OOM killer activity
- Abnormally high memory consumption preceding server crashes
- System logs showing OOM killer invocations targeting the Sliver process
- Multiple concurrent yamux stream connections from a single source
Detection Strategies
- Monitor system memory utilization and alert on rapid memory consumption spikes
- Implement process monitoring to detect unexpected Sliver server terminations
- Review kernel logs for OOM killer events (dmesg | grep -i "out of memory")
- Track yamux stream counts per connection and alert on unusual multiplexing patterns
Monitoring Recommendations
- Enable detailed logging for mTLS and WireGuard transport layer connections
- Implement memory usage thresholds with automated alerting
- Monitor for repeated server crashes that could indicate exploitation attempts
- Review connection patterns for anomalous concurrent stream behavior
How to Mitigate CVE-2026-32941
Immediate Actions Required
- Review the GitHub Security Advisory (GHSA-97vp-pwqj-46qc) for the latest remediation guidance
- Implement network segmentation to limit access to the Sliver C2 server
- Monitor for updates from BishopFox addressing this vulnerability
- Consider deploying the Sliver server in a containerized environment with memory limits
Patch Information
At the time of publication, no official patch was available for this vulnerability. Organizations should monitor the BishopFox Sliver GitHub repository and the security advisory for updates and patch releases. Upgrading to versions above 1.7.3 when a fix becomes available is strongly recommended.
Workarounds
- Deploy Sliver C2 in containers with enforced memory limits (e.g., Docker --memory flag or Kubernetes resource limits) to prevent host-wide impact
- Implement network access controls to restrict which systems can connect to the C2 server
- Consider running Sliver on dedicated infrastructure isolated from critical systems
- Implement automated restart mechanisms to minimize downtime from potential exploitation
# Example: Running Sliver in a container with memory limits
docker run --memory="4g" --memory-swap="4g" sliver-server
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
