Trudesk CVE-2026-114395

Requires a valid authenticated Trudesk session with at least low-privilege user rights (PR:L) - the attacker must be a legitimate account holder, not an anonymous remote attacker. Given that, exploitation needs no special or non-default configuration: the attacker simply issues a POST /api/v1/messages/send request containing attacker-chosen owner and cId parameters against default deployments of Trudesk through 1.2.11, and the server fails to verify that the requester owns the identity or belongs to the target conversation. The primary limiting factor is the authentication requirement; impact is confined to message spoofing/impersonation (integrity), with no confidentiality or availability effect.

This is a moderate-severity integrity issue rather than a top-tier priority. The supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) scores 5.3 and shows a network-reachable, low-complexity attack that requires an authenticated low-privilege account (PR:L) and no user interaction, with impact limited to integrity of the vulnerable system (VI:L) and no confidentiality or availability impact (VC:N/VA:N). The weakness is CWE-639 (authorization bypass / IDOR), consistent with the description of users spoofing message authorship. Real-world risk is tempered by the authentication requirement and the narrow impact - message spoofing/impersonation inside conversations, not data theft or code execution. No EPSS score was provided, so exploitation probability cannot be quantified; the CVE is NOT listed in CISA KEV and no formal proof-of-concept flag is present in the input, although a third-party HackMD write-up and direct source-code line references (messages.js L183-L253) are cited and could materially lower the effort to reproduce. The notable aggravating factor is that this is described as an incomplete fix of CVE-2022-1931, meaning the vendor previously attempted remediation and the control remains bypassable - a pattern that warrants prompt patching despite the modest score. No key signals are internally conflicting: network vector, low privileges, and integrity-only impact all align with an authenticated IDOR.

A low-privileged but authenticated Trudesk user sends a crafted POST /api/v1/messages/send request supplying arbitrary owner and cId values, causing the server to store a message attributed to another user inside a conversation the attacker is not a participant in. This enables impersonation and social-engineering within the helpdesk (e.g., forging messages from staff or other customers). No formal POC is flagged in the input, but a public technical write-up and the exact vulnerable source lines are referenced, making reproduction straightforward.