GHSA-Q8J9-34QF-7VQ7

Vulnerability from github – Published: 2025-10-28 17:31 – Updated: 2025-11-05 22:05
VLAI
Summary
Silver has unrestricted traffic between Wireguard clients
Details

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:

  1. 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

  2. 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) image

  3. The beacon's wireguard private key can be recovered through a process dump or other forensic techniques.

  4. 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: image image image image

  1. Construct a valid Wireguard config based on the strings found. On the attacker's machine, connect to the Wireguard listener.
  2. 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.

Severity
6.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L
Show details on source website
To clipboard 

{
  "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"
        }
      ]
    },
    {
      "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![image](https://github.com/user-attachments/assets/8c791655-6f77-423c-8274-389e0850436b)\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![image](https://github.com/user-attachments/assets/84d3841f-398d-4bca-939f-bf8ed2881be7)\n![image](https://github.com/user-attachments/assets/000c7d02-b6f0-4b12-82e5-29eddfff93f8)\n![image](https://github.com/user-attachments/assets/3d0a3e80-3a16-4434-8622-1832c5865a85)\n![image](https://github.com/user-attachments/assets/a17f73ab-622b-4852-9c15-0ad5c5afa0eb)\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-11-05T22:05:52Z",
  "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"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2025-4079"
    }
  ],
  "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"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

JSON
How durations are calculated

Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.

Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.

Loading timeline…




    Related by attack behaviour

    Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.