⟫ 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 critical attack surface for stored content injection. The platform at trade.voltfunded.com provided a full-featured helpdesk workflow — users could create tickets, submit responses in a threaded conversation format, and upload file attachments. Using Burp Suite Proxy, the response submission flow was intercepted and analyzed, revealing that ticket responses were submitted via the response.content parameter and stored server-side for later rendering in the ticket view interface.
⟫ Vulnerability Discovery
The ticket response rendering mechanism was found to have insufficient output encoding. When a user submitted a response containing HTML or JavaScript content, the backend stored the raw input and the frontend rendered it without proper sanitization or contextual output encoding. The response.content parameter accepted arbitrary HTML markup, which was then persisted in the ticket conversation thread and executed in the browser context of any subsequent viewer — including the ticket creator, other authenticated users, and critically, internal support staff or administrators reviewing tickets through the helpdesk interface.
⟫ 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.
<img src=x onerror=alert(document.cookie)>
// Injected via response.content parameter
// Stored in ticket conversation thread
// Executes on every subsequent ticket viewtrade.voltfunded.com says:
utm_storage={};
_ga=GA1.1.REDACTED.REDACTED;
_fbp=fb.1.REDACTED.REDACTED;
FPLC=REDACTED...
_ym_uid=REDACTED;
_ym_d=REDACTED;
_gcl_au=1.1.REDACTED...
_ym_isad=2;
AMP_MKTG_REDACTED=REDACTED;// Execution Origin: trade.voltfunded.com
// Context: Authenticated user session
// Cookie Access: Full (HttpOnly not set on tracking cookies)
// DOM Access: Full application DOM
// API Access: Authenticated API calls possible
// Target: Any user or staff member viewing the ticket
// Potential escalation:
// - document.cookie → session token theft
// - fetch('/api/...') → authenticated API abuse
// - DOM manipulation → phishing within trusted context⟫ Tooling
⟫ Chaining Strategy & Escalation
The Stored XSS vulnerability in the support ticket workflow presents critical escalation opportunities due to the nature of the attack surface. Support tickets are reviewed by internal staff and potentially administrators — any XSS payload persisted in a ticket response executes in their authenticated browser context. This creates a direct path to session hijacking of privileged accounts. Combined with the IDOR vulnerability previously identified in the same support workflow (ticket creation via customer parameter manipulation), an attacker could: (1) create a ticket under a victim's account via IDOR, (2) inject a Stored XSS payload into the ticket response, (3) wait for support staff to review the ticket, (4) exfiltrate the staff member's session token or perform authenticated actions on their behalf. This exploit chain transforms two individual findings into a comprehensive attack against the platform's internal support infrastructure.
⟫ Root Cause Analysis
The support ticket response rendering mechanism lacked proper output encoding. User-supplied content submitted via the response.content parameter was stored raw and rendered directly into the DOM without contextual HTML entity encoding, JavaScript escaping, or sanitization. The absence of a Content-Security-Policy (CSP) header further compounded the issue by allowing inline script execution and event handler attributes. This is a textbook Stored Cross-Site Scripting vulnerability as defined by CWE-79 (Improper Neutralization of Input During Web Page Generation). The fix requires implementing context-aware output encoding at the rendering layer, input sanitization at the storage layer, and deployment of a strict CSP header to provide defense-in-depth.
⟫ Impact Assessment
⟫ Remediation
Technical Evidence
Visual documentation from the security assessment. All sensitive data has been redacted.
Stored XSS execution on ticket #900175 — alert(document.cookie) fires showing full cookie data. The Response Thread below shows the injected payload via the ticket response interface.
Persistent XSS on ticket #900176 — payload executes on every page load, confirming stored (not reflected) behavior. Cookie data including _ga, _fbp, and tracking tokens exposed.
Payload persistence validation — same ticket viewed in a new session still triggers JavaScript execution, confirming server-side storage of the malicious response content.
Browser execution context — XSS runs within the trade.voltfunded.com origin with full DOM and cookie access. The Reply field and Upload Documents section confirm the authenticated helpdesk context.
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.