⟫ Disclosure Timeline
⟫ Reconnaissance
During authorized security research on the VoltFunded (Exinity) trading platform through the YesWeHack bug bounty program, the support ticket system was identified as a high-value attack surface. The platform exposed a client portal at trade.voltfunded.com with functionality for raising support tickets. Initial reconnaissance involved mapping the support workflow — from the "Raise a Ticket" form to the backend API endpoint. Using Burp Suite Proxy, the ticket creation flow was intercepted, revealing a POST request to https://api.redacted.tld/tickets/cp-create with a JSON body containing user-controlled parameters including subject, description, type, model_id, customer, and priority.
⟫ Vulnerability Discovery
Analysis of the intercepted ticket creation request revealed a critical authorization weakness. The "customer" field in the JSON request body accepted an arbitrary user identifier (MongoDB ObjectId format) that determined ticket ownership. The backend API did not validate whether the provided customer identifier matched the authenticated user's session or JWT token. By extracting the victim's uid from JWT analysis and substituting it in the customer parameter, tickets could be created under any arbitrary user account — demonstrating a classic Broken Object-Level Authorization (BOLA) vulnerability.
⟫ Filter Bypass Analysis
Payloads are intentionally sanitized for responsible disclosure and portfolio presentation.
⟫ Payload Analysis
All payloads below are sanitized proof-of-concept examples. No active exploitation code is shown.
POST /tickets/cp-create HTTP/2
Host: api.redacted.tld
Authorization: Bearer [TOKEN_REDACTED]
Content-Type: application/json
Origin: https://trade.voltfunded.com
Content-Length: 166
{
"subject": "IDOR VALIDATION TEST",
"description": "Authorization bypass testing",
"type": "general",
"model_id": "",
"customer": "VICTIM_OBJECT_ID_REDACTED", ← VICTIM'S ID
"priority": "low"
}{
"status": "ok",
"data": {
"customer": {
"foid": "VICTIM_OBJECT_ID_REDACTED" ← VICTIM'S ID CONFIRMED
},
"type": "general",
"subject": "IDOR VALIDATION TEST",
"description": "Authorization bypass testing",
"pipeline": {
"foid": "PIPELINE_ID_REDACTED"
},
"stage": "incoming",
"stage_status": "open",
"archived": false,
"created_at": {
"date": { "numberLong": "TIMESTAMP_REDACTED" }
}
}
}// JWT Header
{
"sub": "REDACTED",
"typ": "JWT",
"alg": "HS256",
"jti": "JTI_REDACTED"
}
// JWT Payload
{
"iss": "REDACTED",
"jti": "JTI_REDACTED",
"iat": TIMESTAMP_REDACTED,
"uid": "ATTACKER_OBJECT_ID_REDACTED", ← ATTACKER'S UID
"exp": TIMESTAMP_REDACTED,
"_auth_type": 1,
"ua": "web"
}⟫ Tooling
⟫ Chaining Strategy & Escalation
The IDOR vulnerability in the support ticket system creates multiple escalation pathways. First, an attacker can perform silent ticket injection into any user's account by enumerating or harvesting customer ObjectIds — this enables targeted harassment, false support requests, or social engineering through seemingly legitimate platform communications. Second, when combined with other potential vulnerabilities (e.g., Stored XSS in ticket fields, or customer ID enumeration via other API endpoints), the attack chain becomes significantly more dangerous. A Stored XSS payload injected into a victim's support ticket would execute in the context of any support agent who reviews the ticket — potentially leading to administrative session hijacking. Third, the response leaks internal pipeline identifiers and ticket metadata, which could be leveraged for further reconnaissance against the platform's internal systems.
⟫ Root Cause Analysis
The /tickets/cp-create API endpoint trusted the client-supplied "customer" field to determine ticket ownership without performing server-side authorization validation. Although the request included a valid JWT Authorization bearer token containing the authenticated user's uid, the backend did not cross-reference the token's uid with the customer parameter in the request body. This is a textbook Broken Object-Level Authorization (BOLA/IDOR) weakness as defined by CWE-639 (Authorization Bypass Through User-Controlled Key). The API should enforce that the customer parameter matches the authenticated user's identity, rejecting any mismatch between the JWT subject and the target customer identifier.
⟫ Impact Assessment
⟫ Remediation
Technical Evidence
Visual documentation from the security assessment. All sensitive data has been redacted.
Attacker's VoltFunded dashboard — empty ticket list confirming no prior tickets exist before exploitation.
Support ticket creation form — the "Raise a Ticket" interface where the IDOR payload was crafted via intercepted POST request.
Burp Suite Proxy interception — POST /tickets/cp-create request showing the user-controlled "customer" parameter with victim's MongoDB ObjectId highlighted.
JWT bearer token analysis — uid field (attacker's identifier) does not match the customer parameter (victim's identifier), confirming authorization bypass.
IDOR exploitation — request with attacker's JWT but victim's customer ID. Server response confirms ticket creation under victim's account with status "ok".
Victim's dashboard — injected ticket now appears in victim's ticket list, confirming cross-account injection.
Attacker's dashboard remains empty — the ticket was silently created under the victim's account without any trace on the attacker's side.
This case study follows responsible disclosure practices. All sensitive data including endpoints, credentials, customer information, and active exploitation payloads have been redacted or sanitized. The vulnerability was reported through the official bug bounty program and has been resolved.