Trudesk EUVD-2026-107248

No special configuration is required: the regex-injection username enumeration works against a default, internet-reachable Trudesk instance (through 1.2.11) because the POST /api/v1/login handler passes attacker-controlled input into a MongoDB regex query and returns distinguishable 'Invalid User' versus 'Invalid Password' messages. The exploitation is limited strictly to disclosure of valid usernames - it does not grant authentication, code execution, or data modification - and its value depends on the instance being network-reachable to the attacker and on the application still returning the two distinct error responses (behavior that a fix or front-end proxy normalizing login errors would neutralize).

This is a genuinely moderate, not critical, issue - the CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) correctly reflects remote, unauthenticated, low-complexity access, but the only impact metric set is VC:L (low confidentiality) with VI:N/VA:N, consistent with CWE-943 regex/NoSQL injection used purely for username enumeration rather than code execution, auth bypass, or data destruction. The 6.9 score is driven by the easy, unauthenticated network reach, not by severe impact. No EPSS score is provided in the input, so exploitation probability cannot be quantified. KEV status is not indicated (not listed), and no POC flag is set, so there is no public exploit identified at time of analysis - though a detailed technical writeup (hackmd) and a VulnCheck advisory exist, which lower the effort to reproduce it. No SSVC decision data is provided. Signals are internally consistent (network vector matches the HTTP endpoint described), so there is no CVSS-versus-description conflict here; the main gap is the absence of EPSS/KEV/SSVC inputs, meaning real-world exploitation frequency is unknown and the practical risk is best treated as an information-disclosure precursor rather than a standalone emergency.

An unauthenticated attacker sends a series of crafted POST requests to /api/v1/login supplying regex patterns such as (admin|root) or a.* in the username field, then compares the server's 'Invalid User' versus 'Invalid Password' responses to confirm which accounts exist. The harvested list of valid usernames is then fed into password-spraying or targeted phishing against the Trudesk instance. No public exploit is identified at time of analysis, but a step-by-step technical writeup is referenced, making reproduction straightforward.