TeamPlus Messenger CVE-2026-110445

Exploitation requires a TeamPlus Messenger user to actively interact with attacker-crafted content (UI:A), and critically requires that same user to then confirm/accept a Windows security warning dialog before arbitrary code executes - so success is gated by two distinct user actions and depends on social-engineering the victim past an OS-level trust prompt. No authentication is required of the attacker (PR:N) and the vector is network-reachable, but code execution is limited to the privileges of the current (victim) user, not SYSTEM/admin. The chief limiting factors are the mandatory user interaction and the Windows warning prompt, which a security-aware user could decline to abort the attack.

The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H) scores 8.6 (High) and indicates a network-reachable, low-complexity flaw requiring no privileges but ACTIVE user interaction (UI:A). This is a genuine code-injection/RCE issue (CWE-94) but its real-world risk is materially tempered by the interaction requirement: the description makes clear the attacker must trick a user into interacting with crafted content AND the user must additionally click through a Windows security warning before arbitrary code executes. These two human-in-the-loop gates mean exploitation is opportunistic/social-engineering-dependent rather than wormable. No EPSS score, no CISA KEV listing, and no public POC were provided in the input, so there is no evidence of active exploitation or available exploit code at time of analysis. There is no SSVC decision data supplied. Net assessment: a credible RCE worth patching promptly for organizations running TeamPlus Messenger, but not a drop-everything, mass-exploitation emergency given the double user-interaction barrier and absence of any exploitation signal. The product's regional/enterprise-specific footprint (reported via TWCERT) further narrows the threat surface.

An attacker crafts malicious content (e.g., a message or link) and lures a TeamPlus Messenger user into interacting with it, causing arbitrary JavaScript to be injected and executed within the client. The user is then presented with a standard Windows security warning; if they confirm it, the payload runs arbitrary code with that user's privileges. No public exploit code was identified in the provided data, so a live attack would require the adversary to develop the payload independently.