I'm publicly disclosing three high-severity vulnerabilities I discovered in the Suno.com web application on October 9, 2025, after the vendor failed to engage in a proper coordinated disclosure process.
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
scuttmc•3mo ago
This is not a proper disclosure and appears like it was templated or written by AI. So you alerted the company yesterday of the problem, and because they didn't respond how you liked you just disclosed it to the public right away?
theelderemo•3mo ago
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