Websocket
Monthly
Bandit, the pure-Elixir HTTP/WebSocket server, keeps running a WebSock application's handler code after the server has initiated a close, so a remote client that ignores the Close frame can still reach handle_in/2 and handle_info/2 with the state from the {:stop, ...} tuple. Versions 0.5.1 through 1.14.0 are affected (fixed in 1.14.0), and the practical impact lands on WebSock applications that use {:stop, ...} to enforce authorization - a client refused in init/1 after a failed token check, or a kicked/banned user (including Phoenix's :socket_drain path), can keep invoking sensitive actions until it sends Close, TCP drops, or the idle timeout fires, and each client frame resets that timeout. The vendor advisory includes a step-by-step proof-of-concept walkthrough; a public PoC reference exists, but it is not verified as working exploit code, and there is no confirmed active exploitation (CISA KEV).
Improper verification of the WebSocket opening handshake in AsyncHttpClient (AHC) versions prior to 3.0.12 and 2.16.1 lets a malicious or man-in-the-middle WebSocket endpoint have frames decoded and delivered to the application's WebSocketListener even though the server's Sec-WebSocket-Accept value was missing or invalid and the 101 upgrade was never authenticated. Only Java applications that use the WebSocketUpgradeHandler on an affected AHC release and connect to an attacker-controlled or intercepted endpoint are exposed, and because the request future still fails and the channel is closed the window for delivering coalesced frames is narrow and the impact is limited to integrity of listener-delivered data. No public exploit code has been identified at time of analysis and the issue is not known to be actively exploited, consistent with its low CVSS 3.1 score of 3.7 (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).
@fastify/websocket provides WebSocket support for Fastify. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
An integer overflow vulnerability exists with the length of websocket frames received via a websocket connection. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
Bandit, the pure-Elixir HTTP/WebSocket server, keeps running a WebSock application's handler code after the server has initiated a close, so a remote client that ignores the Close frame can still reach handle_in/2 and handle_info/2 with the state from the {:stop, ...} tuple. Versions 0.5.1 through 1.14.0 are affected (fixed in 1.14.0), and the practical impact lands on WebSock applications that use {:stop, ...} to enforce authorization - a client refused in init/1 after a failed token check, or a kicked/banned user (including Phoenix's :socket_drain path), can keep invoking sensitive actions until it sends Close, TCP drops, or the idle timeout fires, and each client frame resets that timeout. The vendor advisory includes a step-by-step proof-of-concept walkthrough; a public PoC reference exists, but it is not verified as working exploit code, and there is no confirmed active exploitation (CISA KEV).
Improper verification of the WebSocket opening handshake in AsyncHttpClient (AHC) versions prior to 3.0.12 and 2.16.1 lets a malicious or man-in-the-middle WebSocket endpoint have frames decoded and delivered to the application's WebSocketListener even though the server's Sec-WebSocket-Accept value was missing or invalid and the 101 upgrade was never authenticated. Only Java applications that use the WebSocketUpgradeHandler on an affected AHC release and connect to an attacker-controlled or intercepted endpoint are exposed, and because the request future still fails and the channel is closed the window for delivering coalesced frames is narrow and the impact is limited to integrity of listener-delivered data. No public exploit code has been identified at time of analysis and the issue is not known to be actively exploited, consistent with its low CVSS 3.1 score of 3.7 (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).
@fastify/websocket provides WebSocket support for Fastify. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
An integer overflow vulnerability exists with the length of websocket frames received via a websocket connection. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.