Exposed SonarQube logins and password spraying
The short version: A SonarQube login exposed to the internet lets attackers quietly spray common and already-breached passwords across your accounts until one works — no exploit required, just an exposed login and one weak credential.
What you need to know
There's no CVE here and nothing to patch. The weakness is the combination of exposure and weak authentication: a login an attacker can reach, in front of accounts whose passwords may be guessable, reused from another site, or already sitting in a public breach dump. SonarQube ships with a well-known default administrative account, which makes an exposed instance an especially attractive target.
Password spraying is the technique that turns that combination into access. Rather than guess many passwords against one account (which trips lockouts), an attacker tries a few high-probability passwords against many accounts, slowly and quietly.
- How they find it — routine internet-wide scanning surfaces exposed SonarQube login pages.
- How they use it — automated, low-and-slow spraying with common and previously-breached passwords, plus attempts against the default admin account.
- What it leads to — SonarQube analyzes source code, so access exposes code, project structure, and often the vulnerabilities the tool has already catalogued — a map of where the soft spots are. Configured integrations and tokens can extend that reach into CI/CD.
How serious we see it
Moderate — by default, with honest upside risk. An exposed login protected by strong, unique credentials, a changed default admin password, and enforced MFA is a manageable exposure, not an emergency. But the real severity depends on what's behind the door: if the default admin password is still in place, or any account uses a weak or reused password without MFA, this quietly becomes High — a direct, unauthenticated path to source code and known-weakness intelligence. The reassuring part is that it's entirely in your hands to fix, with no vendor patch required.
What to do
- Change the default admin credentials immediately — an unchanged default is the fastest way in.
- Enforce MFA and strong authentication — via your identity provider where possible; it defeats spraying even when a password is known.
- Get SonarQube off the open internet — restrict it to trusted networks or a VPN; a code-analysis server rarely needs to be public.
- Limit and monitor failed authentication — alert on spray patterns (many accounts, few passwords, low-and-slow).
- Confirm your exposure first — verify whether any SonarQube login is reachable from the internet at all.
How BreachRisk sees it
BreachRisk discovers SonarQube login portals exposed to the internet the way an attacker would — by crawling your external footprint — and then, where authorized, goes a step further than a scanner: it safely attempts a bounded, rate-limited authentication check using exposed (breach-corpus) and common credentials, within strict non-disruptive limits rather than a brute-force flood. That's the honest difference between detecting a login and demonstrating whether it actually holds. "We have a SonarQube login on the internet" becomes a straight answer: is it defended, or one reused (or default) password away from your source?