Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
8 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Sliver is vulnerable to a Denial of Service (DOS) attack because there is no cap in the size of a PNG file that can be sent to an open http listener and there is a small amount of possible nonces. This vulnerability lets the attacker completely max out the RAM of the machine running server, leading to a complete loss of availability. Details The first vulnerability is that the amount of possible nonces is 65,537. This is found in server/encoders/encoders.go The second vulnerability is there is no limit to how many pixels the PNG encoder will accept from an unauthenticated user. This is found in: util/encoders/images.go PoC The first step to reproduce this vulnerability is building a docker container to make sure no harm is caused. Get the latest version of Sliver (Currently 1.7.3) Build the Docker container: Run the Docker container with a memory cap for example 4GB: After the Docker container starts, create an http listener on port 8080: In a seperate terminal create the…
Recommended action: Upgrade to 1.7.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A single click on a malicious link gives an unauthenticated attacker immediate, silent control over every active C2 session or beacon, capable of exfiltrating all collected target data (e.g. SSH keys, ntds.dit) or destroying the entire compromised infrastructure, entirely through the operator's own browser. Description The Sliver MCP server runs inside the Sliver Client and binds an unauthenticated HTTP and SSE interface to localhost:8080 by default. The service returns a permissive Access-Control-Allow-Origin: header on all responses. Because this server is client-side, the attack surface is distributed across every individual operator in the operation. Any arbitrary website can issue cross-origin requests and interact with the MCP interface via an operator's browser, no credentials required. If the interface is misconfigured to bind to all interfaces (0.0.0.0), the vulnerability escalates from a client-side CSRF/CORS issue to direct, unauthenticated remote access from any actor on…
Recommended action: Upgrade to 1.7.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The DNS C2 listener accepts unauthenticated TOTP bootstrap messages and allocates server-side DNS sessions without validating OTP values, even when EnforceOTP is enabled. Because sessions are stored without a cleanup/expiry path in this flow, an unauthenticated remote actor can repeatedly create sessions and drive memory exhaustion. Vulnerable Component - server/c2/dns.go:84-90 (EnforceOTP stored but not enforced in bootstrap) - server/c2/dns.go:378-390 (TOTP requests routed directly to bootstrap) - server/c2/dns.go:490-521 (handleHello allocates session without OTP validation) - server/c2/dns.go:495 (sessions.Store with no lifecycle control in this path) - client/command/jobs/dns.go:46-52 (operator-facing EnforceOTP control implies auth gate) - implant/sliver/transports/dnsclient/dnsclient.go:896-900 (otpMsg sends TOTP with ID=0) - protobuf/dnspb/dns.proto:22 (documents TOTP in ID field) Attack Vector - Network-accessible DNS listener - No authentication required -…
Recommended action: Upgrade to 1.6.12 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A Path Traversal vulnerability in the website content subsystem lets an authenticated operator read arbitrary files on the Sliver server host. This is an authenticated Path Traversal / arbitrary file read issue, and it can expose credentials, configs, and keys. Affected Component - Website content management (gRPC): WebsiteAddContent, Website, Websites - Server-side file read in Website.ToProtobuf Impact - Arbitrary file read as the Sliver server OS user. - Exposure of sensitive data such as operator configs, TLS keys, tokens, and logs. Root Cause The server accepts and persists arbitrary website paths from the operator, then later reads from disk using that path without sanitization or containment. Vulnerable Code References - server/rpc/rpc-website.go:100 — accepts content.Path from operator RPC and persists it via website.AddContent - server/db/models/website.go:52 — reads from disk with filepath.Join(webContentDir, webcontent.Path) without validating or constraining…
Recommended action: Upgrade to 1.6.11 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/bishopfox/sliver <= 1.5.43; < 1.5.44
Fixed in
1.5.44· Vendor fix available
Issue
Sliver's custom Wireguard netstack doesn't limit traffic between Wireguard clients, this could lead to: 1. Leaked/recovered keypair (from a beacon) being used to attack operators. 2. Port forwardings usable from other implants. Details 1. Sliver treat operators' Wireguard config and beacon/session's Wireguard config equally, they both connect to the wireguard listener created from the CLI. 2. The current netstack implementation does not filter traffic between clients. I think this piece of code handle traffic between clients, from experimental results clients can ping and connect to each other freely, and I didn't see any filtering here either: 3. The docs says to use a Wireguard clients and operator wg-config to connect to the same WG listener as beacons: https://sliver.sh/docs?name=Port%20Forwarding 4. If the operator uses official wireguard clients that integrates with the OS's netstack (I'm using the Windows client) then their services are accessible on the wireguard…
Recommended action: Upgrade to 1.5.44 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/bishopfox/sliver >= 1.5.26, <= 1.5.42
Fixed in
1.5.43· Vendor fix available
Issue
The reverse port forwarding in sliver teamserver allows the implant to open a reverse tunnel on the sliver teamserver without verifying if the operator instructed the implant to do so Reproduction steps Run server Generate binary Run it on windows, then Task manager - find process - Create memory dump file Install RogueSliver and get the certs Start callback listener. Teamserver will connect when POC is run and send "ssrf poc" to nc Run the poc (pasted at bottom of this file) Details We see here an envelope is read from the connection and if the envelope.Type matches a handler the handler will be executed The available handlers: If we send an envelope with the envelope.Type equaling MsgTunnelData, we will enter the tunnelDataHandler function The createReverseTunnelHandler reads the envelope, creating a socket for req.Rportfwd.Host and req.Rportfwd.Port. It will write recv.Data to it Impact For current POC, mostly just leaking teamserver origin IP behind redirectors. I am 99%…
Recommended action: Upgrade to 1.5.43 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/bishopfox/sliver >= 1.5.40, <= 1.6.0-dev
Fixed in
1.6.0· Vendor fix available
Issue
Sliver version 1.6.0 (prerelease) is vulnerable to RCE on the teamserver by a low-privileged "operator" user. The RCE is as the system root user. Impact As described in a past issue, "there is a clear security boundary between the operator and server, an operator should not inherently be able to run commands or code on the server." An operator who exploited this vulnerability would be able to view all console logs, kick all other operators, view and modify files stored on the server, and ultimately delete the server. Reproduction First configure the Sliver server in multiplayer mode and add an operator profile. Next, compile a slightly older version of the Sliver client. The commit after 5016fb8d updates the Cobra command-line parsing library in the Sliver client to strictly validate command flags. The latest server version is targeted: The exploit uses a command injection in the generate msf-stager to inject the --out flag to msfvenom. We overwrite Sliver's own go binary…
Recommended action: Upgrade to 1.6.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The current cryptography implementation in Sliver up to version 1.5.39 allows a MitM with access to the corresponding implant binary to execute arbitrary codes on implanted devices via intercepted and crafted responses. (Reserved CVE ID: CVE-2023-34758) Details Please see the PoC repo. PoC Please also see the PoC repo. To setup a simple PoC environment, 1. Generate an implant with its C2 set to the PoC server's address and copy the embedded private implant key and public server key into the config json. 2. Run the implant on a separate VM and a notepad.exe window should pop up on the implanted VM. Impact A successful attack grants the attacker permission to execute arbitrary code on the implanted device. References https://github.com/BishopFox/sliver/blob/master/implant/sliver/cryptography/implant.go https://github.com/BishopFox/sliver/blob/master/implant/sliver/cryptography/crypto.go https://github.com/tangent65536/Slivjacker Credits Ting-Wei Hsieh from CHT Security Co. Ltd.
Recommended action: Upgrade to 1.5.40 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.