GHSA-q8j9-34qf-7vq7
Vulnerability from github
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
-
Sliver treat operators' Wireguard config and beacon/session's Wireguard config equally, they both connect to the wireguard listener created from the CLI.
-
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
-
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 interface's IP address (for example 100.64.0.3) when the services listen on 0.0.0.0 (SSH, RDP, SMB, etc)
-
The beacon's wireguard private key can be recovered through a process dump or other forensic techniques.
- 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:
- Construct a valid Wireguard config based on the strings found. On the attacker's machine, connect to the Wireguard listener.
- 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
- Filter traffic between clients with a default-deny policy.
- Differentiate between operators and beacons' wireguard config/client
- Only allow specific one-way traffic when the operator request to open a Wireguard port forward.
Vulnerable versions
All versions containing wireguard functionality.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.5.43"
},
"package": {
"ecosystem": "Go",
"name": "github.com/BishopFox/sliver"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.5.44"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-27093"
],
"database_specific": {
"cwe_ids": [
"CWE-284"
],
"github_reviewed": true,
"github_reviewed_at": "2025-10-28T17:31:32Z",
"nvd_published_at": "2025-10-28T20:15:47Z",
"severity": "MODERATE"
},
"details": "### Summary\nSliver\u0027s custom Wireguard netstack doesn\u0027t limit traffic between Wireguard clients, this could lead to:\n1. Leaked/recovered keypair (from a beacon) being used to attack operators.\n2. Port forwardings usable from other implants.\n\n\n### Details\n1. Sliver treat operators\u0027 Wireguard config and beacon/session\u0027s Wireguard config equally, they both connect to the wireguard listener created from the CLI.\n\n2. The current netstack implementation does not filter traffic between clients. \nI think this piece of code handle traffic between clients, from experimental results clients can ping and connect to each other freely, and I didn\u0027t see any filtering here either:\n```\nFile: server\\c2\\wireguard.go\n246: func socketWGWriteEnvelope(connection net.Conn, envelope *sliverpb.Envelope) error {\n247: \tdata, err := proto.Marshal(envelope)\n248: \tif err != nil {\n249: \t\twgLog.Errorf(\"Envelope marshaling error: %v\", err)\n250: \t\treturn err\n251: \t}\n252: \tdataLengthBuf := new(bytes.Buffer)\n253: \tbinary.Write(dataLengthBuf, binary.LittleEndian, uint32(len(data)))\n254: \tconnection.Write(dataLengthBuf.Bytes())\n255: \tconnection.Write(data)\n256: \treturn nil\n257: }\n258: \n\n```\n3. The docs says to use a Wireguard clients and operator wg-config to connect to the same WG listener as beacons:\nhttps://sliver.sh/docs?name=Port%20Forwarding\n\n4. If the operator uses official wireguard clients that integrates with the OS\u0027s netstack (I\u0027m using the [Windows client](https://www.wireguard.com/install/)) then their services are accessible on the wireguard interface\u0027s IP address (for example 100.64.0.3) when the services listen on 0.0.0.0 (SSH, RDP, SMB, etc) \n\n\n5. The beacon\u0027s wireguard private key can be recovered through a process dump or other forensic techniques.\n6. 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\u0027 knowledge, in that way achieve persistence inside the wireguard network.\n\n\n### PoC\nEasy way:\n1. Create 2 operators wireguard config.\n2. Connect them both to the wireguard listener.\n3. From one machine, ping/scan/connect to the other\u0027s services like RDP (3389), SSH (22), etc.\n\nSlightly complicated way:\n1. From the operator\u0027s machine, connect to the wireguard listener.\n2. On the attacker\u0027s machine, run a beacon.\n3. Dump the process\n4. Find the private key, public key, endpoint, etc in the dump file:\n\n\n\n\n\n5. Construct a valid Wireguard config based on the strings found. On the attacker\u0027s machine, connect to the Wireguard listener.\n6. Ping/scan/connect to the other\u0027s services like RDP (3389), SSH (22), etc.\n\n### Impact\nThe operator\u0027s 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).\n\n### Suggestion\n1. Filter traffic between clients with a default-deny policy.\n2. Differentiate between operators and beacons\u0027 wireguard config/client\n3. Only allow specific one-way traffic when the operator request to open a Wireguard port forward.\n\n### Vulnerable versions\nAll versions containing wireguard functionality.",
"id": "GHSA-q8j9-34qf-7vq7",
"modified": "2025-10-29T14:47:34Z",
"published": "2025-10-28T17:31:32Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/BishopFox/sliver/security/advisories/GHSA-q8j9-34qf-7vq7"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-27093"
},
{
"type": "WEB",
"url": "https://github.com/BishopFox/sliver/commit/8e5c5f14506d6d60ebb3362e6b9857ab1e0d76ff"
},
{
"type": "WEB",
"url": "https://github.com/BishopFox/sliver/commit/9122878cbbcae543eb8210f616550382af2065fd"
},
{
"type": "PACKAGE",
"url": "https://github.com/BishopFox/sliver"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
],
"summary": "Silver has unrestricted traffic between Wireguard clients"
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.