GHSA-wxrw-gvg8-fqjp
HIGHSliver has DNS C2 OTP Bypass that Allows Unauthenticated Session Flooding and Denial of Service
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Blast Radius
github.com/bishopfox/sliverReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
Summary
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(EnforceOTPstored but not enforced in bootstrap)server/c2/dns.go:378-390(TOTPrequests routed directly to bootstrap)server/c2/dns.go:490-521(handleHelloallocates session without OTP validation)server/c2/dns.go:495(sessions.Storewith no lifecycle control in this path)client/command/jobs/dns.go:46-52(operator-facingEnforceOTPcontrol implies auth gate)implant/sliver/transports/dnsclient/dnsclient.go:896-900(otpMsgsendsTOTPwithID=0)protobuf/dnspb/dns.proto:22(documents TOTP inIDfield)
Attack Vector
- Network-accessible DNS listener
- No authentication required
- Low-complexity repeated DNS query loop
- Trigger path:
DNSMessageType_TOTPbootstrap handling
Proof of Concept
Preconditions
- DNS listener is reachable
- DNS C2 job is active
Reproduction Steps
- Send repeated DNS queries with a minimal protobuf message of type
TOTP. - Observe repeated session allocation/issuance behavior.
- Continue requests to increase active in-memory session state.
Example
while true; do
dig +short @<DNS_C2_IP> baa8.<parent-domain> A >/dev/null
done
baa8 is a base32 payload for a minimal TOTP-type protobuf message.
Observable Indicators
- Repeated bootstrap/session-allocation log entries from
handleHello - Rising memory usage in the Sliver server process
- Service slowdown or instability under sustained request volume
Impact
- Unauthenticated remote denial of service (availability)
- Resource exhaustion through unbounded session growth in DNS bootstrap path
- Estimated CVSS v3.1:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H(7.5 High)
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/bishopfox/sliver | all versions | 1.6.12 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/bishopfox/sliver. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update github.com/bishopfox/sliver to 1.6.12 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-wxrw-gvg8-fqjp is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-wxrw-gvg8-fqjp is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-wxrw-gvg8-fqjp. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-wxrw-gvg8-fqjp in your dependencies?
O3 detects GHSA-wxrw-gvg8-fqjp across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.