GHSA-c279-989m-238f

### 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/u