BishopFox's Sliver is a command and control (C2) framework that utilizes a custom WireGuard netstack for implant communications. Versions up to and including 1.7.3 contain a vulnerability (CVE-2026-29781) stemming from a lack of nil-pointer validation in the Protobuf unmarshalling logic within the Sliver C2 server. Specifically, when an authenticated actor possessing valid implant credentials crafts a signed message that omits certain nested fields, the server attempts to dereference a NULL pointer during unmarshalling. This triggers an unhandled runtime panic, causing the server process to crash. The vulnerability is particularly impactful on the mTLS, WireGuard, and DNS transport layers because these lack the panic recovery middleware that the HTTP transport layer has, resulting in a complete server termination rather than graceful error handling. The consequence is a denial-of-service condition that acts as an effective kill-switch, instantly disconnecting all implants and active sessions managed by the server. Recovery requires manual intervention to restart the server. While exploitation requires prior authentication (captured implant credentials), the vulnerability can disrupt entire Sliver C2 infrastructures. No patches or mitigations have been publicly released at the time of disclosure. The CVSS 4.0 score is 2.1, reflecting the requirement for authentication and limited confidentiality or integrity impact, but the availability impact is significant within the affected environment.

The primary impact of CVE-2026-29781 is a denial-of-service condition on the Sliver C2 infrastructure. Successful exploitation causes the Sliver server process to crash, severing all active implant sessions and disrupting command and control operations. This can halt offensive security operations or red team activities relying on Sliver, causing operational delays and requiring manual server restarts. While the vulnerability does not directly expose sensitive data or allow privilege escalation, the loss of availability can severely impact organizations using Sliver for security testing or adversary simulation. Additionally, if an attacker gains implant credentials, they can weaponize this flaw as a kill-switch to disrupt an entire Sliver deployment. The lack of panic recovery in non-HTTP transports exacerbates the impact. Since no patches exist, organizations remain exposed until a fix is released or mitigations are applied. The vulnerability's requirement for authentication limits exploitation to actors with some level of access, reducing risk from external attackers but increasing risk from insider threats or compromised implants.

Given the absence of official patches, organizations should implement the following mitigations: 1) Restrict and monitor access to implant credentials rigorously to prevent unauthorized actors from gaining authentication. 2) Employ network segmentation and strict access controls around the Sliver C2 server to limit exposure to authenticated users only. 3) Monitor Sliver server logs and network traffic for unusual or malformed signed messages that could indicate exploitation attempts. 4) Consider deploying the Sliver server behind a proxy or wrapper that implements panic recovery middleware for all transport layers, especially mTLS, WireGuard, and DNS, to prevent process termination on malformed inputs. 5) Prepare operational procedures for rapid manual restart of the Sliver server to minimize downtime if a crash occurs. 6) Engage with BishopFox or the Sliver community to track patch releases and apply updates promptly once available. 7) Limit the number of implants and credentials distributed to reduce the attack surface. 8) Conduct regular security audits of implant credential management and server configurations to detect potential weaknesses.