Trudesk EUVD-2026-107241

Requires a valid authenticated Trudesk account (any low-privilege user, per CVSS PR:L) with access to the ticket comment/note/create APIs; exploitation works against default configurations because the server trusts a client-supplied ownerId or owner field in postComment, postInternalNote, and ticket-create requests rather than deriving ownership from the session. The limiting factor is that unauthenticated outsiders cannot exploit it - an account is mandatory - and impact is confined to forging authorship/integrity of tickets, comments, and internal notes; no confidentiality or availability impact and no admin privileges are needed to perform the forgery.

This is a moderate-severity integrity issue, not an urgent priority. The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) and the 5.3 base score are internally consistent with the description: exploitation is network-reachable and low-complexity but requires an authenticated low-privilege account (PR:L), and impact is limited to integrity (VI:L) with no confidentiality (VC:N) or availability (VA:N) effect. No EPSS score, CISA KEV listing, or confirmed public exploit code was provided, so there are no signals of active or automatable mass exploitation; the risk is that of a logic/authorization flaw (CWE-639, IDOR-style user-controlled key) usable for data forgery rather than system compromise. A detailed third-party technical write-up (hackmd) and the exact vulnerable source lines are referenced, which lowers the barrier to developing an exploit even though no weaponized tooling is cited. All signals agree this is a genuine but contained issue: real where Trudesk is deployed with multiple semi-trusted users, but low real-world urgency given the authentication requirement and integrity-only impact. Missing data to note: no EPSS and no KEV/POC flags were supplied, so exploitation likelihood is inferred from the vector and write-up rather than confirmed.

A logged-in Trudesk user with an ordinary (low-privilege) account sends a postComment, postInternalNote, or ticket-create API request and includes an attacker-chosen ownerId or owner field, causing the server to attribute the content to another user such as an administrator. The attacker thereby plants forged administrator-authored comments, internal notes, or tickets on any ticket, enabling social-engineering or repudiation attacks. A public technical write-up documenting the flaw and the exact vulnerable controller code exists, but no weaponized exploit tool is cited.