GitHub Security Advisory: GHSA-hx52-cv84-jr5v
Package: github.com/bishopfox/sliver (GO)
Severity: LOW (CVSS 0.0)
CWE: CWE-476: NULL Pointer Dereference
Vulnerable versions: <= 1.7.3
Patched in: unpatched

Summary: Sliver is Vulnerable to Authenticated Nil-Pointer Dereference through its Handlers

Details:
## 1. Executive Summary
A vulnerability exists in the Sliver C2 server's Protobuf unmarshalling logic due to a systemic lack of nil-pointer validation. By extracting valid implant credentials and omitting nested fields in a signed message, an authenticated actor can trigger an unhandled runtime panic. Because the mTLS, WireGuard, and DNS transport layers lack the panic recovery middleware present in the HTTP transport, this results in a global process termination. While requiring post-authentication access (a captured implant), this flaw effectively acts as an infrastructure "kill-switch," instantly severing all active sessions across the entire fleet and requiring a manual server restart to restore operations.

## 2. Vulnerability Details
### 2.0 Technical Workflow: From Envelope to Handler
Sliver encapsulates all C2 traffic in a generic `sliverpb.Envelope`, which acts as a routing wrapper. When the server receives an Envelope with `Type = 53` (MsgBeaconRegister), the internal router strips the envelope and passes the raw `Data` bytes directly to the vulnerable `handlers.beaconRegisterHandler(implantConn, data)`. This flow is consistent across all transports, but the **error handling** of the transport itself determines the final impact.

### 2.1 BeaconRegister Nil-Pointer Dereference
- **Vulnerability Type:** Remote Denial of Service via Nil-Pointer Dereference ([CWE-476](https://cwe.mitre.org/data/definitions/476.html))
- **Component:** `server/handlers/beacons.go`
- **Affected Functions:** [beaconRegisterHandler](https://github.com/BishopFox/sliver/blob/master/server/handlers/beacons.go#L46-L110).
- **Severity:** Critical
- **Complexity:** Low

#### Root Cause Analysis
The core of the vulnerability lies in the architectural handling of Protobuf messages within the Go runtime. In `proto3`, all fields are optional by design. When a message contains a nested sub-message (like `Register` inside `BeaconRegister`), the Go Protobuf implementation represents this sub-message as a **pointer**.

In `server/handlers/beacons.go`, the server unmarshals the incoming data without subsequent validation of its nested structures:
```Go
func beaconRegisterHandler(implantConn *core.ImplantConnection, data []byte) *sliverpb.Envelope {
    // ...
    beaconReg := &sliverpb.BeaconRegister{}
    err := proto.Unmarshal(data, beaconReg)
	// Successful even if 'Register' sub-message is omitted
    
    // VULNERABILITY: beaconReg.Register is nil if omitted by sender.
    // Accessing any property of a nil pointer triggers an immediate runtime panic.
    beaconRegUUID, _ := uuid.FromString(beaconReg.Register.Uuid) 
    // ...
}
```

If an attacker constructs a `BeaconRegister` message and deliberately omits the `Register` field, `proto.Unmarshal` parses the stream without error but leaves the `Register` pointer as `nil`. The subsequent attempt to access `beaconReg.Register.Uuid` triggers a **Nil-Pointer Dereference**.
### 2.2 Expanded Inventory: System-Wide Nil-Pointer