Trudesk CVE-2026-111345

Requires a valid authenticated Trudesk account (PR:L) - exploitation is not possible unauthenticated. No non-default configuration is needed: the GET /api/v1/messages/conversation/:id endpoint lacks participant/authorization checks in default deployments of Trudesk through 1.2.11, so any logged-in user can read any conversation by supplying its ID. Practical limiting factors: the attacker must first obtain an account (risk rises sharply where self-service registration is enabled), and must know or enumerate valid conversation IDs; impact is confined to message content and participant PII (usernames, full names, email addresses), with no write or availability impact.

This is a genuine but moderate-severity confidentiality issue rather than a critical priority. The 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: network-reachable, low attack complexity, no user interaction, but requiring an authenticated account (PR:L), with only confidentiality impact (VC:L, VI:N, VA:N) and no scope change. The key limiting signal is PR:L - exploitation is trivial once an attacker holds ANY valid Trudesk account, so the real risk is highest for instances with open/self-service registration or many low-trust users, and lowest for small closed deployments. No EPSS score was provided and the CVE is NOT in CISA KEV, so there is no evidence of active or widespread exploitation. A public technical writeup (hackmd) documents the exact vulnerable request, which lowers the skill barrier considerably. Note one point to verify: the official vector rates confidentiality as Low (VC:L), yet the flaw reportedly exposes full message history plus participant usernames, full names and email addresses across arbitrary conversations via ID enumeration - a defender could reasonably argue the real confidentiality impact is higher than Low. Overall: a real, easily-exploited authorization/IDOR bug worth patching promptly, but constrained by the authentication requirement and the product's limited deployment footprint.

An attacker who holds any low-privilege Trudesk account (e.g. via self-registration) sends GET /api/v1/messages/conversation/:id while substituting conversation IDs belonging to other users. Because the endpoint performs no participant check, the server returns the full message history and participants' usernames, full names and email addresses. A public hackmd writeup detailing the exact request lowers the barrier, and because attack complexity is low (AC:L) the attacker can script ID enumeration to harvest private conversations at scale.