A profile IDOR and stored XSS in a support dashboard

I returned to a platform I had tested a few months earlier and found two unrelated problems in one afternoon. The first exposed complete user profiles through a numeric identifier. The second turned support-ticket filenames into stored JavaScript inside the staff dashboard.

Both findings were reported together. The developer confirmed both fixes the next morning.

Finding one: profile data by user ID

An account-verification endpoint accepted a userId query parameter and returned the complete profile object for that identifier. It did not limit the response to the current account or require permission to inspect the selected user.

GET /api/auth/verify?userId=<numeric_user_id>

Changing the numeric value returned another user's profile. The object included:

• private email address
• the account's full permission list
• administrator and moderator flags
• role names
• system-role indicators

The IDs were predictable enough that sequential requests could have turned the issue into bulk collection. The role data made the leak worse because it identified privileged accounts directly.

This was an object-level authorization failure. The endpoint selected an account from user-controlled input without establishing that the requester was allowed to read that profile.

Finding two: stored XSS in attachment filenames

The support dashboard built attachment markup by concatenating filenames into HTML attributes. Double quotes were not escaped correctly. A crafted filename could break out of its intended attribute and add executable markup.

The payload was stored with the ticket. It executed later, when a support agent or administrator opened that ticket in the dashboard.

Code running in a staff session could potentially:

• send authenticated API requests with the staff member's privileges
• read other tickets or sensitive logs available to that role
• modify account state through staff-only actions
• reach session material if any relevant token was exposed to JavaScript

I used a harmless alert during controlled testing. I did not send a payload to another person's ticket or attempt any privileged action.

Why the bugs were different

The profile endpoint was a privacy problem caused by missing authorization. The ticket bug was a trust-boundary problem caused by inserting untrusted text into HTML.

The profile fix needed an authorization rule tied to the authenticated account, plus a response that returned only necessary fields. The attachment fix needed context-aware output encoding or safe DOM APIs that treat a filename as text.

Disclosure timeline

• 21 March 2026, 5:47 PM: reported both findings
• 22 March 2026, 4:18 AM: developer confirmed both issues were fixed
• 22 March 2026: payment offered for the disclosure and an older outstanding reward

The turnaround was under eleven hours. That did not erase the original exposure, but it sharply reduced the time the known issues remained live after disclosure.