Skip to content
Fencer Intel
high —

GHSA-c279-989m-238f json

Sliver: Nil Pointer Dereference in tunnelCloseHandler causes panic when a reverse tunnel (rportfwd) close is attempted

published 7mo ago modified 7mo ago also GO-2026-4899

cvss
—
not scored
cisa kev
Not listed
not in CISA's catalog
epss
—
no score, EPSS covers CVEs only
public exploits
0
none known

Summary

### Summary A nil pointer dereference in `tunnelCloseHandler` causes the handler goroutine to panic whenever a reverse tunnel (rportfwd) close is attempted. Both the legitimate close path AND the unauthorized close path dereference `tunnel.SessionID` where `tunnel` is guaranteed nil. This means rportfwd tunnels can never be cleanly closed, and any authenticated implant can trigger repeated goroutine panics.

### Details File: `server/handlers/sessions.go` lines 172 and 175

The function enters an `else` block precisely because `core.Tunnels.Get(tunnelData.TunnelID)` returned `nil`. Both conditions inside that else block then dereference `tunnel.SessionID` instead of `rtunnel.SessionID`: ```go } else { rtunnel := rtunnels.GetRTunnel(tunnelData.TunnelID)

if rtunnel != nil && session.ID == tunnel.SessionID { // LINE 172 — nil deref rtunnel.Close() rtunnels.RemoveRTunnel(rtunnel.ID) } else if rtunnel != nil && session.ID != tunnel.SessionID { // LINE 175 — nil deref sessionHandlerLog.Warnf("...") } } ```

Note: The identical bug was already fixed in `tunnelDataHandler` at lines 124/126 (correctly uses `rtunnel.SessionID`), but the fix was not applied to `tunnelCloseHandler`.

### PoC ```go tunnel := GetTunnel(999) // returns nil — no normal tunnel with this ID // tunnel is nil here

rtunnel := GetRTunnel(999) // returns valid rtunnel owned by session-AAAA

// Both lines below panic with: // runtime error: invalid memory address or nil pointer dereference if rtunnel != nil && sessionID == tunnel.SessionID { ... } // line 172 } else if rtunnel != nil && sessionID != tunnel.SessionID { ... } // line 175 ```

Confirmed on master commit `7ac4db3fa` with standalone reproducer. Output: ``` PANIC on line 172 (legitimate close): runtime error: invalid memory address or nil pointer dereference PANIC on line 175 (unauthorized close): runtime error: invalid memory address or nil pointer dereference ```

![1](https://github.com/user-attachments/assets/93b24286-3282-454f-80a4-b01abe4f1d63) ![2](https://github.com/user-attachments/assets/d4219aea-eb18-474c-b69a-a5e20e97161f) ![3](https://github.com/user-attachments/assets/5a76b0d7-ae5b-4d91-bfe9-730d3e5c322c)

### Impact - rportfwd tunnels **cannot be closed** — functional regression - Any authenticated implant can trigger repeated handler goroutine panics - rtunnel map entries leak (never cleaned up on close failure) - `recoverAndLogPanic()` prevents full server crash but silently drops the close operation

### Fix Replace `tunnel.SessionID` with `rtunnel.SessionID` on both lines: ```diff - if rtunnel != nil && session.ID == tunnel.SessionID { + if rtunnel != nil && session.ID == rtunnel.SessionID { rtunnel.Close() rtunnels.RemoveRTunnel(rtunnel.ID) - } else if rtunnel != nil && session.ID != tunnel.SessionID { + } else if rtunnel != nil && session.ID != rtunnel.SessionID { ```

Is GHSA-c279-989m-238f in your dependencies? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.

Check with Fencer

Affected packages

ecosystem package affected fixed in
go github.com/bishopfox/sliver
<=1.7.3
all versions
no fix listed

Classification

Weakness

References

Sources

Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.