Bandit CVE-2026-110314

Exploitation requires the deployed WebSock application to rely on {:stop, ...} return tuples to enforce security - e.g. refusing a client in init/1 after a failed token check, or kicking/banning a user (including Phoenix's :socket_drain, which returns {:stop, {:shutdown, :restart}, ...}) - and to have sensitive logic in handle_in/2 or handle_info/2 that remains reachable after that stop. The attacker needs no authentication (PR:N) - the whole defect is that a refused or terminated client keeps running handlers; the attacker must actively ignore the server's Close frame and keep sending (masked) frames before the client Close, TCP drop, or idle timeout ends the process, and each client frame resets that idle timeout. Limiting factors: applications that do not use {:stop, ...} for authorization, or that treat post-stop frames benignly, are not exploitable; only bandit versions 0.5.1 through <1.14.0 are affected, and updating to 1.14.0 (or applying the advisory workaround of marking the state stopped and returning {:ok, state} without acting) removes the condition.

This is a moderate-priority authorization-bypass issue, not a high-CVSS-but-low-risk item nor a drop-everything emergency. The supplied CVSS 4.0 vector (CVSS:3.1 absent) scores 6.3/Medium with AV:N/AC:L/PR:N/UI:N and low confidentiality and integrity impact (VC:L/VI:L, VA:N), meaning a remote unauthenticated client can reach handler code with no user interaction. The decisive nuance is AT:P (Attack Requirements: Present): exploitation only matters when the target WebSock application relies on {:stop, ...} return tuples to enforce authorization, refuse sessions in init/1, or kick/ban users - so the real-world blast radius is gated by application design, not by Bandit alone. No EPSS score is provided, so exploitation probability cannot be quantified. There is no CISA KEV entry in the input, so this is not confirmed actively exploited; the vuln.today decision label is 'this_month', indicating patch within the month rather than act_now/emergency. The GHSA advisory includes a documented proof-of-concept (failed-token init/1 followed by a post-Close delete_all_users frame), so a public PoC reference exists, but the input does not mark it as confirmed working exploit code. In short: credible, patchable, and clearly reproducible in affected app designs, but bounded by the AT:P condition and lacking EPSS/KEV signals that would escalate it.

A WebSock application returns {:stop, :normal, {4401, "unauthorized"}, state} from init/1 when a token check fails, and runs an admin-only delete_all_users action in handle_in/2. An attacker upgrades with ?user_id=admin&token=wrong; the server calls terminate/2 and sends a Close frame (code 4401) but keeps the process in :closing state, so when the attacker ignores the Close and sends a masked text frame 'delete_all_users', handle_in/2 still executes it as admin. The advisory documents this as a step-by-step PoC; it is not verified in the input as standalone working exploit code.