CVE-2026-32941 affects BishopFox's Sliver command and control (C2) framework, specifically versions 1.7.3 and earlier. Sliver uses a custom WireGuard netstack and mTLS for secure communication between the server and implants. The vulnerability arises from the way the Sliver server processes incoming messages: the socketReadEnvelope and socketWGReadEnvelope functions read a 4-byte length prefix from attacker-controlled input to determine memory allocation size. The ServerMaxMessageSize parameter allows single allocations up to approximately 2 GiB. An attacker who has valid credentials or controls a compromised implant can exploit this by sending maliciously crafted length prefixes over up to 128 concurrent yamux streams within a single connection. This can cause the server to attempt allocating roughly 256 GiB of memory, overwhelming system resources and triggering an out-of-memory kill by the operating system. This results in a crash of the Sliver server, terminating all active implant sessions and potentially impacting other processes on the same host due to resource exhaustion. The implant-side readers share the same flawed pattern but lack any upper-bound checks, making implants themselves vulnerable to similar memory exhaustion attacks. At the time of disclosure, no patch or fix has been released. The vulnerability is classified under CWE-770 (Allocation of Resources Without Limits or Throttling) and CWE-789 (Uncontrolled Memory Allocation). The CVSS 4.0 vector indicates network attack vector, low attack complexity, no privileges required beyond valid credentials, no user interaction, and high impact on availability. No known exploits are reported in the wild yet.

The primary impact of CVE-2026-32941 is a denial-of-service condition caused by forced out-of-memory crashes of the Sliver C2 server. This disrupts all active implant sessions, effectively halting ongoing operations relying on the Sliver framework. For organizations using Sliver for red teaming, penetration testing, or adversary simulation, this can cause significant operational disruption and loss of control over deployed implants. Additionally, the OOM condition may affect other critical processes running on the same host, potentially leading to broader system instability or downtime. Since the vulnerability requires valid credentials or a compromised implant, attackers with insider access or who have already breached implant security can leverage this to escalate impact. The implant-side vulnerability also raises the risk of implant crashes, which could alert defenders or reduce attacker persistence. While no known exploits are currently reported, the ease of exploitation with valid credentials and the high resource consumption make this a notable risk for organizations relying on Sliver C2 infrastructure.

1. Restrict access to the Sliver C2 server strictly to trusted and authenticated users to minimize the risk of exploitation by unauthorized actors. 2. Monitor network traffic and logs for unusual patterns such as multiple concurrent yamux streams or abnormally large length prefixes in messages. 3. Implement resource limits at the operating system or container level to cap memory usage by the Sliver server process, preventing system-wide OOM conditions. 4. Consider isolating the Sliver server on dedicated hosts or virtual machines to contain potential crashes and avoid collateral impact on other critical services. 5. Disable or limit concurrent yamux streams if configurable, to reduce the attack surface for memory exhaustion. 6. Regularly check for updates or patches from BishopFox and apply them promptly once available. 7. If possible, audit implant code and communication patterns to detect and prevent malformed messages that could trigger the implant-side memory exhaustion. 8. Employ network segmentation and zero-trust principles to limit lateral movement and reduce the chance of implant compromise. 9. Prepare incident response plans to quickly recover from Sliver server crashes and restore implant sessions.