EUVD-2026-116542
GHSA-96v4-jjm6-m9vg
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessDiscover locked MiroTalk room
-
ExploitSend repeated checkPassword guesses
-
ExecutionBrute-force password without lockout
-
ImpactJoin private meeting room
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A07:2025 - Authentication Failures
ASVS 5.0
V6 - Authentication Brute-force prevention, rate limiting
|
| Exploitation Conditions | Exploitation requires the target MiroTalk P2P room to be password-locked (peers[channel]['lock'] === true with a password set); against such a room an unauthenticated remote attacker (PR:N) can send repeated pre-join 'checkPassword' socket.io events, which in versions up to 2.0.87 performed a plain password comparison with no attempt counter or lockout, enabling unlimited guessing. Limiting factors: the attack only applies to password-locked rooms, practical success depends on the room password being weak or guessable (the input states exploitation is difficult/highly complex), and the attacker must know or discover a valid room ID; rooms without a password lock are unaffected. |
| Impact | This is a medium-severity, not an emergency-grade, issue. The vendor CVSS 4.0 score is 6.3 (CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:P): network-reachable and unauthenticated (PR:N), but high attack complexity (AC:H) and only limited confidentiality impact (VC:L) with no integrity or availability impact. The weakness (CWE-307) is a missing lockout/throttle on the room-password check, confirmed by the patch diff which introduces per-IP+room failure counting and a 15-minute lockout. The input explicitly states exploitation is difficult/highly complex, which is consistent with AC:H and with the fact that practical success still depends on the room password being weak or guessable. No EPSS score is provided and the CVE is not on CISA KEV, so there is no signal of widespread or active exploitation. A public PoC reference exists (a 'checkpassword-oracle' write-up) but it is not verified as working exploit code, so POC availability must not be read as active exploitation. The vuln.today decision label is 'this_month', indicating a patch-on-normal-cadence priority rather than act_now/emergency. Net: a real but bounded brute-force/oracle weakness against locked rooms; worth patching this cycle, not a drop-everything event. |
| Exploit ScenarioDerived | An attacker who knows or guesses a MiroTalk P2P room ID targets a password-locked room and repeatedly submits candidate passwords via the pre-join checkPassword socket event, which in vulnerable versions applies no rate limiting or lockout. By iterating guesses unthrottled, the attacker can brute-force a weak room password and join a private meeting. A public PoC reference describing a checkPassword password oracle exists, but it is not verified as working exploit code. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Nov 03, 2026
Password guessing against locked MiroTalk P2P meeting rooms is effectively unlimited in versions up to 2.0.87, because the pre-join 'checkPassword' Socket.IO handler in app/src/server.js compares the supplied password with a plain string equality check and keeps no attempt counter or lockout, letting unauthenticated remote attackers fire guesses at will and use the 'OK'/'KO' reply as an oracle. Exposure is narrow: the target room must actually be password-locked and its room ID known or discoverable, and success still depends on the room password being weak or guessable, which is why this is rated medium severity rather than urgent. A public PoC reference exists but is not verified as working exploit code, there is no confirmed active exploitation (CISA KEV), and the vendor has released a fix in 2.1.38.
RemediationAI
Vendor-released patch: 2.1.38 - upgrade MiroTalk P2P to 2.1.38 or later, which ships the new app/src/roomPassword.js module enforcing 5 failed attempts per IP-and-room within a 15-minute window followed by a 15-minute block, constant-time password comparison, and removal of the room password from debug log output; the change is applied both to the pre-join 'checkPassword' path and to the locked-room join handler. Because the advisory's stated affected ceiling (2.0.87) and the commit's version bump (2.1.37 → 2.1.38) do not line up, upgrade any instance older than 2.1.38 rather than relying on the version string. Until patched, the practical exposure is bounded by password strength: choose long, random, non-guessable room passwords so the unthrottled guessing has no realistic chance of success, since rooms without a password lock are unaffected, and treat the room password as the only barrier - the pre-fix code offers no attempts-based protection of its own. The public PoC reference at https://github.com/waterhunter2000-svg/vulnerability-reports/blob/main/04-mirotalk-checkpassword-oracle.md is not verified as working exploit code but describes the guessing oracle, so prioritize internet-facing instances that host password-locked rooms.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
MiroTalk P2P is a Node.js WebRTC meeting application built on Express and Socket.IO, where each room is tracked in a server-side 'peers' map holding a 'lock' flag and a 'password' value; the flaw is CWE-307 (Improper Restriction of Excessive Authentication Attempts). Before the fix, the 'checkPassword' socket event handler in app/src/server.js evaluated 'password == peers[room_id][\'password\']' and returned 'OK' or 'KO' to the caller with no per-client or per-room failure accounting, so an unauthenticated remote client (CVSS 4.0 vector PR:N, AV:N) could enumerate guesses indefinitely over a persistent Socket.IO connection. The committed patch (55bec1d05f931d2e43633d6d0b7274f79ec719dd) introduces a new app/src/roomPassword.js module that keys attempt state on 'IP|roomId', blocks further attempts after 5 failures within a 15-minute window for the remainder of that window, and clears the counter on success; it also replaces loose equality with SHA-256 digests compared via crypto.timingSafeEqual (removing a comparison-timing side channel) and removes the submitted password from the room debug log line, which is consistent with the 'Information Disclosure' tag attached to the report. The room-join path that validates channel_password for locked rooms was hardened the same way. AC:H reflects that the attacker must still guess a secret correctly; the trigger is a deliberately crafted pre-join event, not an automatic condition.
Know when Mirotalk P2P gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:P
Network-reachable and unauthenticated (AV:N/PR:N/UI:N); AC:H because success is probabilistic and depends on a weak room password and the room being locked; only limited room-access confidentiality impact (C:L), no integrity/availability effect.
Primary rating from Vendor (VulDB).
CVSS VectorVendor: VulDB
Lifecycle Timeline
3DescriptionCVE.org
A vulnerability was found in miroslavpejic85 MiroTalk P2P up to 2.0.87. This vulnerability affects the function checkPassword of the file app/src/server.js of the component Room Action Handler. The manipulation results in improper restriction of excessive authentication attempts. It is possible to launch the attack remotely. Attacks of this nature are highly complex. It is stated that the exploitability is difficult. The exploit has been made public and could be used. Upgrading to version 2.1.38 is able to resolve this issue. The patch is identified as 55bec1d05f931d2e43633d6d0b7274f79ec719dd. Upgrading the affected component is advised.
Threat Intelligence Overview
NVD
CVE.org
VulDB
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
More in Mirotalk P2P
View allA cross-site scripting (XSS) vulnerability in MiroTalk P2P before commit f535b35 allows attackers to execute arbitrary w
Improper access control in the Socket.IO signaling handlers of MiroTalk P2P through version 2.1.38 (and the 2.0.87 line)
Exploit-DB