Loading vulnerability…
The WebSocket Application Programming Interface (API) does not enforce restrictions (rate limiting) on the number of authentication requests that can be made. An attacker can abuse this by sending excessive authentication attempts, which can enable denial-of-service conditions (e.g., suppressing or mis-routing legitimate charger telemetry) and can also facilitate brute-force authentication attempts to obtain unauthorized access.
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
If you can’t patch tonight, do this now.
Patch, then assume compromise.
1 valid exploit after Mallory filtered fakes, detection scripts, and README-only repos.
This repository is a JavaScript/Node.js proof-of-concept simulator for a claimed CVE-2026-27778 affecting a WebSocket-based authentication flow. It is not tied to a known exploit framework. The core structure consists of: (1) server-side simulators in server.js and run.js, (2) a browser dashboard in index.html, and (3) an attack client in attack.js. package.json starts server.js via nodemon. The main exploit capability is repeated AUTH_REQ submission over WebSocket to abuse missing or weak brute-force protections (CWE-307 style behavior). attack.js opens a WebSocket to a placeholder target and sends password guesses every 50 ms until an AUTH_RES with success=true is received. server.js simulates the vulnerable target more completely: it accepts PING and AUTH_REQ messages, tracks totals/success/fail/blocked counts, broadcasts METRICS and logs to all connected clients every second, and intentionally performs a heavy synchronous loop during auth handling. In MODE 2 it simulates weak blocking after a configurable number of failures; in MODE 1 it effectively allows unrestricted guessing; the heavy loop also makes each auth attempt consume CPU, enabling availability degradation. run.js is a variant monitoring server that broadcasts all auth results globally and emits periodic TELEMETRY messages. It also supports a MODE 3 path with a larger CPU-burning loop, reinforcing the DoS/resource exhaustion simulation. The browser UI in index.html connects back to the same host via ws:// or wss://, sends periodic PING messages, graphs RTT using Chart.js, and displays logs, bypass ratio, availability, lag, and request rate. Notable findings: the repository appears to include accidental code inside .gitignore, duplicating another server implementation. The exploit is operational rather than weaponized: it contains working attack logic and a hardcoded brute-force pattern, but no flexible payload generation or framework integration. Overall, the repository’s purpose is to demonstrate and visualize brute-force abuse and service degradation against a WebSocket authentication endpoint, rather than deliver a stealthy real-world intrusion toolkit.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.
4 sources tracked across advisories and community write-ups. News coverage will land here when it surfaces.
No news coverage yet. Advisories and community discussion only.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.