WebSocket Authentication Brute-Force via Missing Rate Limiting (CVE-2026-27778)
by KimJ6 · 2026-07-05
- Severity
- Medium
- CVE
- CVE-2026-27778
- Category
- web
- Affected product
- Generic Node.js/Express + ws WebSocket authentication server (demonstration/simulator app)
- Affected versions
- Simulated reference implementation — pattern applies to any WebSocket auth endpoint lacking rate limiting
- Disclosed
- 2026-07-05
- Patch status
- patched
Archive entry
intelseclab/poc-archiveMetadata
| Field | Value |
|---|---|
| Date Added | 2026-07-05 |
| Last Updated | 2026-05 |
| Author / Researcher | KimJ6 |
| CVE / Advisory | CVE-2026-27778 |
| Category | web |
| Severity | Medium |
| CVSS Score | Not specified in source |
| Status | PoC |
| Tags | websocket, brute-force, cwe-307, rate-limiting, authentication, nodejs, simulator |
| Related | N/A |
Affected Target
| Field | Value |
|---|---|
| Software / System | Generic Node.js/Express + ws WebSocket authentication server (demonstration/simulator app) |
| Versions Affected | Simulated reference implementation — pattern applies to any WebSocket auth endpoint lacking rate limiting |
| Language / Platform | JavaScript (Node.js, browser WebSocket client) |
| Authentication Required | No |
| Network Access Required | Yes |
Summary
This repository is a hands-on simulator for CVE-2026-27778 (CWE-307: Improper Restriction of Excessive Authentication Attempts) built around a small Node.js/Express server that accepts WebSocket AUTH_REQ messages containing a password guess and replies with success/failure. Because the server (mode 1) never throttles or locks out repeated authentication attempts on the same connection, a client can flood it with password guesses at a fixed interval until the correct password is found. The included attack.js browser/Node script opens a WebSocket connection and fires an incrementing password guess every 50ms in a tight loop, logging the elapsed time once the server confirms a match. server.js and run.js provide two variants of the vulnerable backend (one with an optional lockout “mode 2” for comparison, one broadcasting auth results to all connected monitoring clients), letting a user directly observe the difference between rate-limited and unprotected configurations.
Vulnerability Details
Root Cause
The WebSocket message handler for AUTH_REQ compares the supplied password to a fixed secret and returns the result immediately, with no per-connection or per-IP attempt counter, delay, or lockout enforced by default (mode 1), allowing unlimited automated guesses.
Attack Vector
- Open a WebSocket connection to the target’s authentication endpoint.
- Continuously send
AUTH_REQmessages with incrementing/dictionary password guesses at a fixed short interval. - Monitor incoming
AUTH_RESmessages for asuccess: trueresponse. - Stop once the correct credential is identified, having brute-forced the password with no throttling encountered.
Impact
Full compromise of the guessable credential via automated brute force, with attack speed limited only by network/server throughput rather than any defensive control.
Environment / Lab Setup
Target: Node.js server (server.js / run.js) exposing a WebSocket AUTH_REQ endpoint on port 3000
Attacker: Node.js or a browser console to run attack.js against ws://<target>:3000
Proof of Concept
PoC Script
See
attack.js,server.js, andrun.jsin this folder.
| |
attack.js opens a WebSocket connection and sends an AUTH_REQ message with an incrementing password guess every 50ms, logging the total elapsed time once the server responds with success: true.
Detection & Indicators of Compromise
Signs of compromise:
- Large volume of failed
AUTH_RES(success: false) responses to a single WebSocket connection in a short window - Sustained ~20 requests/second authentication traffic from one client
- Eventual single
AUTH_RES success: truefollowing a long run of failures from the same source
Remediation
| Action | Detail |
|---|---|
| Primary fix | No vendor patch confirmed as of 2026-07-05 — implement per-connection/per-IP rate limiting and account lockout on authentication endpoints |
| Interim mitigation | Enforce exponential backoff or hard lockout after N failed attempts (as demonstrated by the repo’s “mode 2” configuration), and require CAPTCHA or MFA on WebSocket auth flows |
References
Notes
Mirrored from https://github.com/KimJ6/PoC-Simulator_CVE-2026-27778 on 2026-07-05.
| |