CVE-2026-101089 in Nezha
Summary
by MITRE • 09/28/2026
Nezha before 2.2.7 contains an information disclosure vulnerability in the GET /api/v1/profile endpoint that returns the bcrypt-hashed password field of authenticated users. Attackers can extract password hashes and perform offline cracking attacks without rate limiting or audit trail constraints.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/28/2026
The security flaw identified in Nezha versions prior to 2.2.7 represents a critical information disclosure vulnerability located within the GET /api/v1/profile endpoint. This API route, intended for retrieving user profile data, fails to properly sanitize its response payload by including sensitive authentication credentials that should remain strictly internal. Specifically, the endpoint returns the bcrypt-hashed password field associated with authenticated users directly in the JSON response body. In a secure architectural design, password hashes are stored exclusively within the database and accessed only during the login verification process via server-side comparison logic. They must never be transmitted to client applications or exposed through public-facing API endpoints under any circumstances, as this practice fundamentally violates the principle of least privilege and proper data handling protocols for sensitive credentials.
The operational impact of this vulnerability is severe due to the nature of bcrypt hashing algorithms. While bcrypt hashes are designed to resist immediate reversal through rainbow tables, they remain vulnerable to offline brute-force or dictionary attacks if an attacker obtains them. Because the API endpoint lacks rate limiting mechanisms, an authenticated user with malicious intent can programmatically request profile data for other users at a high frequency without triggering security controls such as account lockouts or IP-based throttling. This absence of access control constraints allows adversaries to extract password hashes from multiple accounts rapidly and efficiently. Furthermore, the lack of audit trail constraints means that these unauthorized extractions may go undetected by system administrators, allowing attackers ample time to perform offline cracking operations against the harvested hashes using powerful hardware accelerators or distributed computing resources.
From a classification perspective, this vulnerability aligns with CWE-200: Information Exposure and CWE-538: Insertion of Sensitive Information into an XML Document if applicable, though more accurately it falls under CWE-269: Improper Privilege Assignment regarding the API endpoint's exposure level, or specifically CWE-14: Compiler Removal of Code to Protect Confidential Data if the hash was stripped during build but not runtime. In terms of attack vectors, this scenario maps directly to MITRE ATT&CK technique T1078: Valid Accounts, where an attacker leverages legitimate credentials to access resources they should not have permission to view, and potentially T1596: Search Open Technical Databases if the hashes are subsequently cracked and used in broader credential stuffing campaigns. The failure to implement proper output encoding or field filtering on sensitive data constitutes a significant deviation from secure coding standards such as OWASP API Security Top 10, specifically failing controls related to Broken Object Level Authorization (BOLA) principles where users should only access their own non-sensitive profile data without exposure of internal system secrets.
To mitigate this vulnerability and prevent similar incidents in the future, immediate remediation requires modifying the backend logic for the GET /api/v1/profile endpoint to explicitly exclude or mask password-related fields from the response payload before serialization. Developers must ensure that no sensitive authentication material, including hashes, tokens, or private keys, is ever included in API responses intended for client consumption. Additionally, implementing robust rate limiting policies on all user-facing endpoints is essential to prevent automated scraping and brute-force extraction attempts. Comprehensive audit logging should be enabled to monitor access patterns to profile data, ensuring that anomalous behavior such as high-frequency requests from a single source can be detected and blocked in real-time. Regular security code reviews focusing on API response sanitization and adherence to OWASP guidelines will further strengthen the application's defense against information disclosure attacks.