WebSocket frames keep reaching the WebSock after a server-initiated close in Bandit

Overview

Client-Side Enforcement of Server-Side Security vulnerability in the WebSocket connection handling of mtrudel bandit allows a remote client to keep running WebSock handler code after the server has stopped its connection, via data frames sent after ignoring the server's Close frame.

When a WebSock callback returns {:stop, ...}, Bandit.WebSocket.Connection calls terminate/2, sends Close and shuts down the write side, but keeps the connection process running in a :closing state. handle_frame/3 and handle_info/3 never check that state, so later frames still reach handle_in/2 and later messages reach handle_info/2, with the state from the stop tuple, until the client sends Close, TCP drops or the idle timeout fires. A client refused in init/1 after a failed token check could still run an admin-only action.

This issue affects bandit: from 0.5.1 before 1.14.0.

Affected

• bandit >= 0.5.1 < 1.14.0
• mtrudel/bandit >= bb407f2277dcb65a58dd8cc07913a0b58a80e266 < 220b9dfd27f9a21305be2afc75cbe585ddc24e7a

Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.

Workarounds

Mark the WebSock state as stopped whenever a callback returns {:stop, ...}, and have handle_in/2 and handle_info/2 return {:ok, state} without acting while that mark is set.