SonarQube Default Credentials and Exposed Consoles

SonarQube holds source metadata, issue data, and often project analysis tokens. Default credentials on a public instance are an easy win—if you verify carefully and keep the dump out of your proof.

Classic pair to know: admin / admin on fresh installs that never completed setup hardening. Variants exist per version and edition. Confirm against the target's docs rather than spraying a huge list.

Recon and fingerprinting

Look for /sessions/new, SonarQube in page titles, and API roots like /api/system/status. The status endpoint frequently returns version and whether the instance is up—useful even before login.

Other signals:

/api/server/version
Default TLS certs on internal hostnames published by mistake
CI variables named SONAR_TOKEN leaked in logs (separate finding)

If login is public, try defaults only when the program allows credential testing. One or two attempts beat a password storm.

Dev and QA instances hide behind predictable hostnames: sonar., sonarqube., codequality.. Corporate VPN-only claims fall apart when the same A record is reachable from cloud scanners. Check HTTP and HTTPS; some installs redirect awkwardly and expose an older vhost without SSO.

What to pull after access

Once in with an owned or default admin, stay minimal:

Note identity and global permissions.
Open one project you can justify (public project, or your own).
Show that you can create a token or view a forced issue—then revoke the token.
Do not bulk-download private source archives for "fun."

Severity jumps when admin can reset other users, generate global analysis tokens, or reach portfolio data for customers outside your account. Cross-org leakage needs a clear tenant boundary explanation.

Weak guest access matters too. Anonymous browse enabled with source download is a finding even without admin. Quote the permission matrix from the UI.

Analysis tokens in CI often have narrower rights than UI admin, yet still upload or read projects. If you found a token in a public workflow log, validate it against /api/authentication/validate or a harmless API call, then revoke or ask the customer to revoke.

Avoid the noisy mistakes

Changing the admin password mid-test locks out the customer. Creating webhooks to your server may violate scope. Deleting projects is sabotage.

If defaults fail, check whether the setup wizard is still exposed, or whether a reverse proxy grants access to /api without the same auth as the UI. API/UI skew shows up more than people expect.

Force-change-password banners you bypass by hitting the API directly are worth documenting. So are forgotten local accounts after SSO was "turned on" for humans only.

Community and commercial editions differ in available auth plugins, yet default local admin mistakes look the same. If the instance is SonarCloud versus self-hosted SonarQube, say which one—remediation owners differ.

Clean report checklist

Include instance URL, version from status API, credential type (default vs weak), permission level, and a screenshot of a non-sensitive project page. Recommend forced password change on first login, SSO, disabling anonymous access, network restriction, and rotating any tokens you generated.

Sonar's administration security pages cover authentication options. Point operators there after you show the open door.