Skip to main content

SonarQube Token

A SonarQube token is a credential used to authenticate API requests to the SonarQube server, which is a platform for continuous inspection of code quality. This token allows users to interact with SonarQube's API to manage projects, analyze code, and retrieve quality metrics. Exposure of a SonarQube token is a significant security concern as it can lead to unauthorized access to code quality data and potentially allow malicious actors to manipulate project settings or data.

How Does It Look​

SonarQube tokens can appear in various contexts, such as:

  • Environment variables:

    export SONARQUBE_TOKEN="sqp_XXXXXXXXXXXXXXXXXXXXXXXXXXXX"

  • Configuration files (YAML):

    sonar:
      token: "sqp_XXXXXXXXXXXXXXXXXXXXXXXXXXXX"

  • Code snippets:

    headers = {"Authorization": "Bearer sqp_XXXXXXXXXXXXXXXXXXXXXXXXXXXX"}

  • Connection strings:

    https://sonarqube.example.com/api/projects/search?token=sqp_XXXXXXXXXXXXXXXXXXXXXXXXXXXX

Severity​

  • 🟠 High

The severity is high because a SonarQube token provides access to the SonarQube API, which can include sensitive project data and configuration settings. If the token has broad permissions, an attacker could manipulate project settings or access sensitive code quality metrics, potentially impacting the integrity of the software development lifecycle.

What Can an Attacker Do?​

With immediate access to a SonarQube token, an attacker can interact with the SonarQube API to perform unauthorized actions.

Key actions an attacker can perform:

  • Access project data: Retrieve sensitive code quality metrics and project configurations (if the token has read permissions).
  • Modify project settings: Change quality gates, rules, or other configurations (if the token has write permissions).
  • Delete projects: Remove projects from the SonarQube server (if the token has administrative permissions).
  • Create new projects: Add unauthorized projects to the server (if the token allows project creation).

An attacker could potentially escalate their access by using the token to gather information about the SonarQube environment, which could lead to further exploitation or lateral movement within the network.

Real-World Impact​

Exposure of a SonarQube token poses significant business risks, particularly in environments where code quality is critical.

Potential consequences include:

  • Data Exposure: Access to sensitive code quality metrics and project configurations (if the token has read access to sensitive data).
  • Operational Disruption: Changes to quality gates or rules could disrupt development processes (if the attacker has modify permissions).
  • Reputational Damage: Unauthorized changes or data exposure could harm the organization's reputation.

In the worst-case scenario, an attacker could manipulate code quality metrics to hide vulnerabilities, leading to insecure software releases and potential exploitation in production environments.

Prerequisites for Exploitation​

To exploit a SonarQube token, an attacker needs:

  • Network access: Ability to reach the SonarQube server.
  • SonarQube server endpoint: Knowledge of the server's URL or IP address.
  • No IP restrictions: The token must not be restricted by IP allowlisting.

How to Verify If It's Active​

To verify if a SonarQube token is active, use the following command:

curl -H "Authorization: Bearer [TOKEN]" https://sonarqube.example.com/api/authentication/validate

Valid credential response: A successful response will indicate that the token is valid, typically returning a JSON object with a status of "true".

Invalid/expired credential response: An invalid or expired token will result in an error message or a JSON object with a status of "false".

Detection Patterns​

Common Variable Names:

  • SONARQUBE_TOKEN
  • SONAR_TOKEN
  • SQ_TOKEN
  • SONAR_AUTH_TOKEN
  • SONAR_API_TOKEN
  • SQ_API_KEY

File Locations:

  • .env
  • config.yml
  • settings.json
  • sonar-project.properties

Regex Pattern:

sqp_[a-zA-Z0-9]{40}

Remediation Steps​

  1. Revoke immediately - Go to SonarQube > Administration > Security > Users and delete the compromised token.
  2. Audit access logs - Review SonarQube access logs for unauthorized API requests during the exposure window.
  3. Assess blast radius - Identify all systems, applications, and environments that used the exposed token.
  4. Rotate credential - Generate a new token in SonarQube with least-privilege permissions.
  5. Update dependent systems - Deploy the new token to all applications and update CI/CD pipelines securely.
  6. Harden access controls - Enable IP allowlisting in SonarQube and require secure connections.
  7. Implement secrets management - Migrate tokens to a secrets manager (HashiCorp Vault, AWS Secrets Manager) to prevent hardcoding.
  8. Add detection controls - Set up pre-commit hooks and repository scanning to catch token leaks before they reach production.

Credential exposures often go undetected for extended periods, increasing the window for exploitation. As a long-term strategy, plan to establish an internal process or engage an external vendor for continuous external exposure monitoring. This helps identify leaked secrets across public repositories, paste sites, dark web forums, and other external sources before attackers can leverage them. Proactive detection and rapid response are essential to minimizing the impact of credential leaks.

References​