Loading vulnerability…
CVE-2026-32941 is a remote denial-of-service vulnerability in Sliver C2 framework versions 1.7.3 and earlier affecting the server's mTLS and WireGuard C2 transport handling. The vulnerable code paths are identified as socketReadEnvelope and socketWGReadEnvelope, which trust an attacker-controlled 4-byte length prefix when allocating buffers for incoming messages. On the server side, ServerMaxMessageSize permits single allocations of roughly 2 GiB. A compromised implant or an attacker with valid credentials can open concurrent yamux streams, up to 128 per connection, and send fabricated length prefixes that cause the server to attempt extremely large memory allocations. This can drive aggregate allocation attempts to approximately 256 GiB and trigger operating system out-of-memory termination. The same unsafe length-handling pattern is also present in implant-side readers, which reportedly lack any upper-bound check.
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
If you can’t patch tonight, do this now.
Patch, then assume compromise.
1 valid exploit after Mallory filtered fakes, detection scripts, and README-only repos.
Small standalone Go PoC repository for a Sliver C2 denial-of-service issue, not part of a larger exploit framework. The repository contains one executable source file (mtls_poc.go), a README, and Go module metadata. The Go code is the main artifact and implements a practical authenticated network DoS against a Sliver mTLS listener. The exploit flow is: load a valid implant-derived client certificate and EC private key, connect to the configured Sliver mTLS endpoint over TLS, send the yamux preface "MUX/1", create a yamux client session, then open many concurrent streams (default 64). On each stream it sends a 74-byte fake signature and a 4-byte little-endian length field set to 2,147,483,647 bytes. According to the code comments, the target server allocates the requested buffer before verifying the Ed25519 signature and before receiving the full body. The PoC intentionally never sends the body and keeps streams open, causing the server to retain huge allocations and block in reads. Repeating this across concurrent streams is intended to exhaust RAM and trigger Linux OOM termination of sliver-server. Repository structure and purpose: - README.md: describes the vulnerability, setup steps, expected impact, and verification commands. - mtls_poc.go: full exploit implementation with hardcoded example endpoint and embedded PEM certificate/key placeholders. - go.mod / go.sum: dependency metadata; notable libraries are hashicorp/yamux and bishopfox/sliver. Notable capabilities: - Authenticated mTLS connection using extracted implant credentials. - Yamux multiplexing to amplify impact over a single connection. - Concurrent stream abuse to force repeated large allocations. - Persistent hold-open behavior to keep memory consumed until the target crashes. This is a real exploit PoC rather than a scanner or detector. It does not provide code execution or persistence; its purpose is service disruption through memory exhaustion.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.
2 sources tracked across advisories and community write-ups. News coverage will land here when it surfaces.
No news coverage yet. Advisories and community discussion only.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.