Stoat Chat EUVD-2026-87768

Requires an authenticated actor able to submit or change a username (PR:L) - specifically the account creation or username-update flow of stoatchat before 0.15.5. Exploitation depends on the server accepting Unicode input in usernames and performing Unicode sanitization/normalization AFTER the character-allowlist and 32-character length checks rather than re-validating afterward. No user interaction by a victim is needed to create the malformed username. Impact is limited to integrity of the username namespace (reserved-name lookalikes, embedded special characters, over-length storage values); there is no confidentiality or availability impact and no privilege elevation beyond identity spoofing.

This is a genuine but modest-severity issue. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N, base 5.3 Medium) tells a consistent story: network-reachable, low complexity, but requires at least low privileges (PR:L - an account able to submit a username) and yields only limited integrity impact with zero confidentiality or availability impact. That aligns well with the CWE-180 root cause (validate-before-canonicalize): forbidden characters are re-introduced only after the allowlist check passes, so the outcome is identity/username spoofing and storage-limit evasion, not code execution or data theft. No EPSS score, no CISA KEV listing, and no public POC were provided, so exploitation is not confirmed in the wild and appears low-urgency. The KEV/EPSS absence is not itself a defect - but combined with a niche product and integrity-only impact, this is a low-to-medium real-world priority rather than a high-CVSS false alarm. One caveat: the input Tag labels this 'Authentication Bypass,' which overstates the impact - the vector shows VI:L only and no authentication or authorization boundary is actually crossed; it is an input-validation/spoofing bypass. Verify the exact abuse surface (e.g., whether reserved-name lookalikes enable impersonation of admins) with the vendor advisory.

An attacker who can register or rename an account submits a username containing Unicode letters that pass the allowlist and length checks, then normalize into forbidden characters or a reserved-name lookalike (e.g., an admin or system name). Because validation runs before Unicode sanitization, the transformed value is stored, letting the attacker impersonate reserved identities, inject special characters, or exceed the 32-character storage limit. No public exploit code was identified at time of analysis, but the technique is straightforward for any authenticated user.