Suno.com Security Disclosure: Jwt Token Leakage, Idor, and Dos Vulnerabilities
Posted3 months agoActive3 months ago
github.comTechstory
calmnegative
Debate
10/100
SecurityVulnerability DisclosureJwt Token
Key topics
Security
Vulnerability Disclosure
Jwt Token
A security researcher disclosed multiple vulnerabilities in Suno.com, including JWT token leakage, IDOR, and DoS vulnerabilities, which were later fixed; the disclosure was met with a calm and matter-of-fact discussion on HN.
Snapshot generated from the HN discussion
Discussion Activity
Light discussionFirst comment
N/A
Peak period
1
0-1h
Avg / period
1
Key moments
- 01Story posted
Oct 10, 2025 at 10:42 AM EDT
3 months ago
Step 01 - 02First comment
Oct 10, 2025 at 10:42 AM EDT
0s after posting
Step 02 - 03Peak activity
1 comments in 0-1h
Hottest window of the conversation
Step 03 - 04Latest activity
Oct 10, 2025 at 3:17 PM EDT
3 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45539648Type: storyLast synced: 11/17/2025, 11:13:48 AM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
The vulnerabilities are:
Finding 1: Excessive Data Exposure / JWT Token Leakage (High Severity): Critical API endpoints return active JWT session tokens directly in the JSON response body. This allows for session hijacking and account takeover by any malicious browser extension, completely bypassing MFA. Suno's response indicated a misunderstanding of client-side threats, claiming that since the client already has the token, it's not an issue.
Finding 2: Broken Object Level Authorization (IDOR) (High Severity): The API does not validate if a user owns a resource before returning data. This allows any authenticated user to access the private content of any other user, including private songs, prompts, and generation history, simply by enumerating user IDs.
Finding 3: Unrestricted Resource Consumption (DoS) (Medium Severity): A batch endpoint for retrieving songs has no server-side limits on the number of IDs that can be requested. This allows an attacker to trigger resource exhaustion and cause a denial of service.
I attempted to responsibly disclose these findings to Suno. They dismissed the first two findings and, most concerningly, suggested I transmit the full proof-of-concept details through a Google Form. After I rejected this insecure method and offered multiple secure alternatives to which they did not respond, I made the decision to publicly disclose to protect users.
For a full technical breakdown, including disclosure timeline, proof-of-concept code, and remediation guidance for both users and Suno, please see the full advisory