☠️
EXFILTRATING
DATA...
01010111 10110010 00101001 11000110 01101100 10011011 00010001 11100101 01000010 10101111
[ <-- BACK_TO_SEARCH ]
Sonarsource logo [ WEBSITE ] [ VENDOR STATS ]
CVSS: 4.3 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N 🐛 CWE-200
👁️
Common Weakness Enumeration - Identifies the specific category of software weakness or flaw.

CVE-2025-62292

CVE-2025-62292 Information Disclosure in Sonarsource
📅 PUBLISHED: 2025-10-10 00:00 UTC 🔄 UPDATED: 2026-10-02 19:21 UTC
[ PATCH UNDER REVIEW ↓ ] Remains UNDER REVIEW until an independent source confirms the fix
[ DEFENSE PATCH ↓ ]
💣 PoC: None
👁️
Proof of Concept - Indicates if functional exploit code is publicly available, drastically increasing the risk of immediate attacks.
🎯 EPSS: 0.04%
👁️
0.04% probability
<1× above the median CVE
Tier: LOW
30-day exploitation window · FIRST.org · updated daily
🥷 MITRE: T1213
👁️
MITRE ATT&CK Tactic - Describes the strategy hackers use to execute this attack.
Country: Switzerland License: Commercial
VULNERABLE: version not auto-detected — verify your deployed version locally
CVSS VECTOR BREAKDOWN 4.3
AV: N Attack Vector Network
AC: L Attack Complexity Low
PR: L Privileges Required Low
UI: N User Interaction None
S: U Scope Unchanged
C: L Confidentiality Low
I: N Integrity None
A: N Availability None
4.3
THREAT LEVEL
■ tracking this CVE ✓ independent patch confirmation ⧗ same-origin mirror (GHSA) ⚠ active exploitation verification policy →

Executive Summary

CVE-2025-62292 is an information disclosure vulnerability in SonarQube, a popular code quality and security analysis platform. The flaw allows authenticated low-privileged users to query the /api/v2/users-management/users endpoint and retrieve sensitive user fields, including email addresses, that should be restricted to administrators only. This exposure violates the principle of least privilege and can facilitate targeted phishing attacks, account enumeration, and social engineering campaigns against the organization.

The vulnerability affects all SonarQube versions prior to 25.6, 2025.3 Commercial, and 2025.1.3 LTA. The CVSS score is 4.3 (Medium), with a low attack complexity and no user interaction required beyond authentication. The EPSS score is 0.0%, indicating no active exploitation in the wild at the time of analysis, but the risk remains significant due to the sensitive nature of the exposed data.

⚡ AUTOMATE YOUR CVE INTELLIGENCE

This record — and 170,000+ others — are available via the ValtersIT API. One endpoint replaces five: NVD + GitHub CVE + CISA KEV + EPSS + Nuclei + Exploit-DB, unified.

›Patch confidence — UNVERIFIED to CONFIRMED, cross-referenced NVD + RHSA + Debian
›Exploit & PoC — poc_status, poc_url, has_exploit. Not in NVD.
›Shodan dorks — ready-made queries to find exposed vulnerable systems
›Detection rules — YARA · Wazuh · Elastic (all plans) · Sigma (Pro)
›pending_fields — know exactly which of 7 fields NVD hasn't processed yet
›Free backfill — data incomplete when you paid? Re-check within 30 days = 0 credits
PAYG €0.08/lookup Standard €19/mo (was €29) · 5k credits Pro €65/mo (was €99) · 20k credits FOUNDING PRICE · LOCKED FOR LIFE · ENDS 31 DEC 2026
[ FROM €19/MO ]
Free sandbox key available
No signup required

Supply Chain & Package Security

This vulnerability is not related to a package manager (NPM, PyPI, Go, Ruby) but is a direct application-level flaw in the SonarQube web API. Organizations using SonarQube as part of their CI/CD pipeline should treat this as a critical supply chain risk, as exposed email addresses can be used to target developers and operations personnel.

CVSS Breakdown & Threat Level

  • Attack Vector (AV): Network (N) – The vulnerability is exploitable remotely over the network.
  • Attack Complexity (AC): Low (L) – No special conditions or race conditions are required.
  • Privileges Required (PR): Low (L) – An attacker needs only a low-privileged account (e.g., a standard user).
  • User Interaction (UI): None (N) – No user interaction is required.
  • Scope (S): Unchanged (U) – The vulnerability does not affect other components.
  • Confidentiality (C): Low (L) – Only email addresses are exposed, not passwords or tokens.
  • Integrity (I): None (N) – No data modification is possible.
  • Availability (A): None (N) – No denial of service.

Threat Level: Medium. While the direct impact is limited to email disclosure, the downstream risks (phishing, social engineering) elevate the overall threat.

Deep Dive & Mechanics

The vulnerability resides in the /api/v2/users-management/users API endpoint. In vulnerable versions, this endpoint does not properly enforce authorization checks for low-privileged users. The API is designed to return a list of users with fields such as login, name, email, and active. The intended behavior is that only administrators should be able to see the email field of other users. However, due to a missing or insufficient permission check, any authenticated user can request this endpoint and receive the full user list, including email addresses.

The flaw is in the backend controller that handles the API request. The code likely checks if the user is authenticated but fails to verify if the user has the admin or scan permission before returning sensitive fields. This is a classic case of Insecure Direct Object Reference (IDOR) or Missing Function Level Access Control.

Vulnerable vs. Patched Code

Vulnerable Code (Conceptual):

// Vulnerable: No permission check before returning user details
@GetMapping("/api/v2/users-management/users")
public ResponseEntity<List<UserDTO>> getUsers() {
    List<UserDTO> users = userService.getAllUsers();
    return ResponseEntity.ok(users);
}

Patched Code (Conceptual):

// Patched: Permission check added
@GetMapping("/api/v2/users-management/users")
public ResponseEntity<List<UserDTO>> getUsers(Principal principal) {
    if (!userService.isAdmin(principal)) {
        return ResponseEntity.status(HttpStatus.FORBIDDEN).build();
    }
    List<UserDTO> users = userService.getAllUsers();
    return ResponseEntity.ok(users);
}

The patch adds a check to ensure the requesting user has administrative privileges before returning the full user list. If the user is not an admin, the endpoint returns a 403 Forbidden status.

Exploitation & Lab Setup

Red Team

Prerequisites:

  • A valid low-privileged user account on a vulnerable SonarQube instance (version < 25.6, < 2025.3 Commercial, or < 2025.1.3 LTA).
  • Network access to the SonarQube web interface.

Exploitation Steps:

  1. Authenticate to the SonarQube instance with the low-privileged account.
  2. Obtain a session token or cookie.
  3. Send a GET request to the vulnerable endpoint:
    GET /api/v2/users-management/users HTTP/1.1
    Host: sonarqube.example.com
    Authorization: Bearer <low_priv_token>
    
  4. The response will contain a JSON array of user objects, each including the email field.

Example Response:

[
  {
    "login": "admin",
    "name": "Admin User",
    "email": "admin@example.com",
    "active": true
  },
  {
    "login": "developer1",
    "name": "Developer One",
    "email": "dev1@example.com",
    "active": true
  }
]

Blue Team

Detection:

  • Monitor for unusual API calls to /api/v2/users-management/users from non-admin users.
  • Alert on multiple rapid requests to this endpoint from the same IP or user account.
  • Correlate with failed login attempts or other reconnaissance activities.

Hunting:

  • Search logs for GET /api/v2/users-management/users with a 200 response code from users without the admin role.
  • Look for patterns of email harvesting, such as repeated requests with different user agents or from unexpected IP ranges.

Indicators of Compromise (IOCs)

  • Network IOCs:
    • HTTP GET requests to /api/v2/users-management/users from non-admin users.
    • Response bodies containing JSON arrays with email fields.
  • Log IOCs:
    • SonarQube access logs showing GET /api/v2/users-management/users with a 200 status code for low-privileged users.
    • Audit logs showing unusual API usage patterns.
  • File IOCs:
    • No specific file-based IOCs, as this is a server-side vulnerability.

Detection Engineering

YARA Rule

rule sonarqube_user_enumeration {
    meta:
        description = "Detects attempts to enumerate users via SonarQube API"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-62292"
    strings:
        $api_path = "/api/v2/users-management/users"
        $json_start = "{"
        $email_field = "\"email\":"
    condition:
        $api_path and $json_start and $email_field
}

Sigma Rule

title: SonarQube User Enumeration via API
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects low-privileged users accessing the user management API to enumerate email addresses.
author: Valters IT
date: 2025/04/10
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2025-62292
logsource:
    category: webserver
    product: sonarqube
detection:
    selection:
        cs-method: 'GET'
        cs-uri-stem: '/api/v2/users-management/users'
        sc-status: 200
    filter:
        cs-username|contains: 'admin'
    condition: selection and not filter
falsepositives:
    - Legitimate admin users performing user management tasks
level: medium

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (
    msg:"CVE-2025-62292 - SonarQube User Enumeration Attempt";
    flow:to_server,established;
    content:"GET";
    http_method;
    content:"/api/v2/users-management/users";
    http_uri;
    pcre:"/^\/api\/v2\/users-management\/users$/U";
    classtype:attempted-recon;
    sid:1000001;
    rev:1;
)

Remediation & Mitigation

Immediate Actions:

  1. Upgrade SonarQube to version 25.6, 2025.3 Commercial, or 2025.1.3 LTA or later.
  2. If immediate upgrade is not possible, restrict access to the /api/v2/users-management/users endpoint using a reverse proxy or WAF rule to allow only admin IPs.
  3. Review and revoke any unnecessary low-privileged accounts.

Long-Term Measures:

  • Implement strict API authorization checks using role-based access control (RBAC).
  • Conduct regular security audits of API endpoints.
  • Monitor for unusual API access patterns.
  • Educate users about phishing risks associated with exposed email addresses.

Workaround:

  • Use a reverse proxy (e.g., Nginx) to block non-admin access to the endpoint:
    location /api/v2/users-management/users {
        allow <admin_ip_range>;
        deny all;
    }
    

Valters IT

👁️ SHODAN DORKS (THREAT HUNTING)

What is this? Security researchers use these exact search queries on Shodan.io (a search engine for internet-connected devices) to find vulnerable systems globally. You can copy these dorks to see if your organization's IP space is exposed.

SonarQube
sonarqube
X-Forwarded-Proto: https
◈ SOURCE Analysis & enrichment: valtersit.com/cve/CVE-2025-62292/ · CVE data: NVD/MITRE (public domain) · © 2026 ValtersIT Hub
>_ SYSTEM_CORE: INTEL_ACTIVE
90% TEAM-CURATED // 10% AUTOMATED INGESTION.
ALL PATCH REFERENCES AND VERSION DATA SOURCED FROM NVD + OSV OFFICIAL REGISTRIES.