Sliver does not restricted traffic between Wireguard clients.

CISA KEV is observed exploitation evidence. FIRST EPSS is a dated prediction of exploitation in the next 30 days. Missing scores are unknown. This collector requests predictions only for explicit CVE aliases in the public NuGet archive; Microsoft release views retain their existing prediction scope.

No collected risk observation for these identifiers. This does not establish absence of exploitation or a zero probability.

Sliver is a command and control framework that uses a custom Wireguard netstack. In versions 1.5.43 and earlier, and in development version 1.6.0-dev, the netstack does not limit traffic between Wireguard clients. This allows clients to communicate with each other unrestrictedly, potentially enabling leaked or recovered keypairs to be used to attack operators or allowing port forwardings to be accessible from other implants.

Source published

28 Oct 2025 19:29:16 UTC

Source modified

29 Oct 2025 17:43:54 UTC

Observed here

23 Oct 2026 15:48:27 UTC

Source terms

CVE Program Terms of Use

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: cve-program · CVE Program Terms of Use. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 3.1 · 6.3 CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L

Sliver is a command and control framework that uses a custom Wireguard netstack. In versions 1.5.43 and earlier, and in development version 1.6.0-dev, the netstack does not limit traffic between Wireguard clients. This allows clients to communicate with each other unrestrictedly, potentially enabling leaked or recovered keypairs to be used to attack operators or allowing port forwardings to be accessible from other implants.

Source published

Oct 28, 2025, 7:29:16 PM (timezone not stated)

Source modified

Oct 29, 2025, 5:43:54 PM (timezone not stated)

Observed here

11 Nov 2026 02:46:51 UTC

Source terms

ENISA EUVD · source terms and attribution apply

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: euvd · ENISA EUVD · source terms and attribution apply. Source text is retained; field grouping and change labels are provided by ChangeIntel.

EUVD CVSS 3.1 · 6.3 CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L

Sliver is a command and control framework that uses a custom Wireguard netstack. In versions 1.5.43 and earlier, and in development version 1.6.0-dev, the netstack does not limit traffic between Wireguard clients. This allows clients to communicate with each other unrestrictedly, potentially enabling leaked or recovered keypairs to be used to attack operators or allowing port forwardings to be accessible from other implants.

Source published

28 Oct 2025 20:15:47 UTC

Source modified

8 Oct 2026 11:10:00 UTC

Observed here

25 Oct 2026 02:24:42 UTC

Source terms

NIST NVD usage terms; underlying source attribution retained

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: nvd · NIST NVD usage terms; underlying source attribution retained. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 3.1 · [email protected] · Secondary · 6.3 CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L

### Summary 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: ``` File: server\c2\wireguard.go 246: func socketWGWriteEnvelope(connection net.Conn, envelope *sliverpb.Envelope) error { 247: data, err := proto.Marshal(envelope) 248: if err != nil { 249: wgLog.Errorf("Envelope marshaling error: %v", err) 250: return err 251: } 252: dataLengthBuf := new(bytes.Buffer) 253: binary.Write(dataLengthBuf, binary.LittleEndian, uint32(len(data))) 254: connection.Write(dataLengthBuf.Bytes()) 255: connection.Write(data) 256: return nil 257: } 258: ``` 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](https://www.wireguard.com/install/)) then their services are accessible on the wireguard interface's IP address (for example 100.64.0.3) when the services listen on 0.0.0.0 (SSH, RDP, SMB, etc)  5. The beacon's wireguard private key can be recovered through a process dump or other forensic techniques. 6. When a private key is recovered, an attacker can connect to 100.64.0.1:1337 (key exchange listener) to generate new wireguard clients without the operators' knowledge, in that way achieve persistence inside the wireguard network. ### PoC Easy way: 1. Create 2 operators wireguard config. 2. Connect them both to the wireguard listener. 3. From one machine, ping/scan/connect to the other's services like RDP (3389), SSH (22), etc. Slightly complicated way: 1. From the operator's machine, connect to the wireguard listener. 2. On the attacker's machine, run a beacon. 3. Dump the process 4. Find the private key, public key, endpoint, etc in the dump file:     5. Construct a valid Wireguard config based on the strings found. On the attacker's machine, connect to the Wireguard listener. 6. Ping/scan/connect to the other's services like RDP (3389), SSH (22), etc. ### Impact The operator's machine is impacted, if their services contain a vulnerability, an attacker can exploit it and gain RCE. If not then it could be used to gather information (Hostname, SSH signature, etc). ### Suggestion 1. Filter traffic between clients with a default-deny policy. 2. Differentiate between operators and beacons' wireguard config/client 3. Only allow specific one-way traffic when the operator request to open a Wireguard port forward. ### Vulnerable versions All versions containing wireguard functionality.

Source published

28 Oct 2025 17:31:32 UTC

Source modified

5 Nov 2025 22:05:52 UTC

Observed here

24 Oct 2026 13:19:41 UTC

Source terms

GitHub Advisory Database · CC-BY-4.0

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · GitHub Advisory Database · CC-BY-4.0. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS_V3 · CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L

Publisher rating · MODERATE

Silver has unrestricted traffic between Wireguard clients in github.com/bishopfox/sliver

Source published

5 Nov 2025 18:41:15 UTC

Source modified

3 Mar 2026 04:57:31 UTC

Observed here

24 Oct 2026 13:19:41 UTC

Source terms

OSV · upstream source license applies

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · OSV · upstream source license applies. Source text is retained; field grouping and change labels are provided by ChangeIntel.