Listen to this Post
The vulnerability resides in the `tunnelCloseHandler` function within server/handlers/sessions.go. When a reverse tunnel (rportfwd) close is requested, the function attempts to retrieve the tunnel using core.Tunnels.Get(). Because the tunnel ID corresponds to a reverse tunnel (not a standard one), this call returns nil. The code then enters an `else` block intended for reverse tunnel handling. Inside this block, it correctly retrieves the reverse tunnel using rtunnels.GetRTunnel(), but the subsequent conditional checks erroneously dereference the `tunnel` variable (which is nil) instead of the `rtunnel` variable. Specifically, lines 172 and 175 attempt to access tunnel.SessionID. This results in a nil pointer dereference, causing the handler goroutine to panic. While a `recoverAndLogPanic()` function prevents a full server crash, it silently drops the close operation and leaves the reverse tunnel entry in the map, causing a memory leak. An authenticated implant can exploit this by repeatedly sending close requests for non-existent or reverse tunnels, triggering repeated goroutine panics and denial of service. The identical bug was previously fixed in `tunnelDataHandler` but was overlooked in the tunnelCloseHandler.
dailycve form is:
Platform: Sliver C2
Version: master commit 7ac4db3fa
Vulnerability : Nil pointer dereference
Severity: Medium
date: 2026-03-30
Prediction: 2026-04-13
Analytics under heading What Undercode Say:
Locate the vulnerable lines in sessions.go grep -n "tunnel.SessionID" server/handlers/sessions.go | grep -E "172|175" Expected output: lines showing the erroneous dereference Extract the commit where the fix was partially applied git show 7ac4db3fa -- server/handlers/sessions.go | grep -A5 -B5 "rtunnel.SessionID"
// Vulnerable code block in tunnelCloseHandler (lines 170-178)
} else {
rtunnel := rtunnels.GetRTunnel(tunnelData.TunnelID)
if rtunnel != nil && session.ID == tunnel.SessionID { // PANIC: tunnel is nil
rtunnel.Close()
rtunnels.RemoveRTunnel(rtunnel.ID)
} else if rtunnel != nil && session.ID != tunnel.SessionID { // PANIC: tunnel is nil
sessionHandlerLog.Warnf("Session %s attempted to close tunnel %d belonging to session %s", session.ID, tunnelData.TunnelID, tunnel.SessionID)
}
}
Exploit:
// Authenticated implant sends close request for a valid rtunnel ID
tunnelClose := &TunnelClose{
TunnelID: 999, // ID of an existing reverse tunnel
}
// This triggers the nil dereference in tunnelCloseHandler
Protection from this CVE
- Upgrade to a patched version containing the fix.
- Apply the fix by replacing `tunnel.SessionID` with `rtunnel.SessionID` in lines 172 and 175 of
server/handlers/sessions.go. - Implement a WAF rule to filter anomalous tunnel close requests if upgrading is not immediately possible.
Impact:
- Denial of service via repeated handler goroutine panics.
- Inability to properly close reverse tunnels (rportfwd), leading to functional regression.
- Memory leak due to unreleased reverse tunnel map entries.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
