# REPRO-2026-00088: Sliver has DNS C2 OTP Bypass that Allows Unauthenticated Session Flooding and Denial of Service

## Summary
Status: published
Severity: Unknown
Type: security
Confidence: Unknown

## Identifiers
REPRO ID: REPRO-2026-00088
GHSA: GHSA-WXRW-GVG8-FQJP


## Package
Name: Unknown
Ecosystem: Unknown
Affected: Unknown
Fixed: Unknown

## Root Cause
## Summary
The Sliver DNS C2 listener in the 1d50db698 (2023) code path accepts unauthenticated DNSMessageType_TOTP bootstrap requests and allocates a new DNSSession for each request even when EnforceOTP is enabled. The TOTP message is treated as a “hello” packet that bypasses any OTP validation, so an unauthenticated remote actor can repeatedly send a tiny protobuf payload and force session allocations without cleanup.

## Impact
- Package/component affected: Sliver server DNS C2 listener (server/c2/dns.go).
- Affected versions: At least commit 1d50db6982880a1e538afac2ad8c5f268e62c51a (June 2023), prior to removal of TOTP bootstrap in Feb 2026.
- Risk level and consequences: High availability risk. A remote unauthenticated actor can flood the DNS listener with minimal TOTP bootstrap messages to create unbounded sessions and memory growth, leading to denial of service.

## Root Cause
The DNS handler routes all DNSMessageType_TOTP messages directly to handleHello without checking the EnforceOTP flag or validating the OTP value. In handleHello, the server allocates a DNSSession and stores it in sessions with a newly generated DNS session ID, and there is no cleanup for this bootstrap path. The bug is visible in server/c2/dns.go: handleC2 checks for TOTP and calls handleHello, while handleHello simply stores a new session. A later fix removes TOTP from DNS C2 and adds pending message GC (commit 9b001ab88ea17b7247f2622c13003c4dcabe5bf3).

## Reproduction Steps
1. Run `repro/reproduction_steps.sh`.
2. The script clones Sliver, checks out commit 1d50db698, adds placeholder assets required for build tags, and runs a minimal DNS listener using StartDNSListener with EnforceOTP=true. It then sends a single base32-encoded DNSMessageType_TOTP query to the listener.
3. Expected evidence: the DNS response contains a non-zero session ID and the script prints “received session id …” followed by “Vulnerability reproduced…”.

## Evidence
- Log file: `logs/dns_totp_poc.log`
- Key excerpt (example): `received session id 196.251.221.137`
- Environment details: Go toolchain go1.20.14 (via GOTOOLCHAIN) with build tags `server go_sqlite` on linux/arm64.

## Recommendations / Next Steps
- Suggested fix: enforce OTP validation in the TOTP bootstrap handler (reject invalid OTPs when EnforceOTP is enabled) and add lifecycle cleanup for sessions created during bootstrap. Preferably remove unauthenticated TOTP bootstrap entirely, as in the Feb 2026 change.
- Upgrade guidance: move to a version that removes TOTP bootstrap and includes session/pending message GC.
- Testing recommendations: add unit/integration tests that send TOTP bootstrap messages with EnforceOTP enabled and assert the server rejects them without creating sessions; add load tests ensuring session tables remain bounded.

## Additional Notes
- Idempotency: `repro/reproduction_steps.sh` was run twice consecutively and succeeded both times.
- Limitations: the script demonstrates session allocation for a single request; sustained flooding would exacerbate memory use but is not required to confirm the bug.

## Reproduction Details
Reproduced: 2026-02-13T15:31:07.707Z
Duration: 802 seconds
Tool calls: 242
Turns: Unknown
Handoffs: 2


## Quick Verification
Run one of these commands to verify locally:

    pruva-verify REPRO-2026-00088
    pruva-verify GHSA-WXRW-GVG8-FQJP


Or open in GitHub Codespaces (zero-friction, auto-runs):

    https://github.com/codespaces/new?ref=repro/REPRO-2026-00088&repo=N3mes1s/pruva-sandbox

Or download and run the script manually:

    curl -O https://api.pruva.dev/v1/reproductions/REPRO-2026-00088/artifacts/repro/reproduction_steps.sh
    chmod +x reproduction_steps.sh
    ./reproduction_steps.sh

WARNING: Run in a sandboxed environment. This exploits a real vulnerability.

## References
- GitHub Advisory: https://github.com/advisories/GHSA-WXRW-GVG8-FQJP



## Artifacts
- repro/rca_report.md (analysis, 3109 bytes)
- repro/reproduction_steps.sh (reproduction_script, 2681 bytes)
- vuln_variant/rca_report.md (analysis, 3620 bytes)
- vuln_variant/reproduction_steps.sh (reproduction_script, 4115 bytes)
- bundle/ticket.md (ticket, 2129 bytes)
- logs/dns_totp_poc.log (log, 35 bytes)
- logs/dns_totp_variant.log (log, 253 bytes)

## API Access
- JSON: https://api.pruva.dev/v1/reproductions/REPRO-2026-00088
- Script: https://api.pruva.dev/v1/reproductions/REPRO-2026-00088/artifacts/repro/reproduction_steps.sh
- Web: https://pruva.dev/r/REPRO-2026-00088

## For AI Assistants
To help users with this reproduction:
1. The `pruva-verify` command is the simplest way to run the reproduction
2. The script downloads and runs automatically in an isolated temp directory
3. Always recommend running in a VM, container, or disposable environment
4. The root cause explains the technical vulnerability

---
Generated by Pruva | https://pruva.dev