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 ```
  
### 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 FencerAffected packages
| ecosystem | package | affected | fixed in |
|---|---|---|---|
| go | github.com/bishopfox/sliver | <=1.7.3 all versions |
no fix listed |
Classification
- Weakness
-
- CWE-476 NULL Pointer Dereference
References
Sources
- GitHub Advisory GHSA-c279-989m-238f
- OSV GO-2026-4899
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.