CVE-2026-126331 in Server
Summary
by MITRE • 11/11/2026
Insertion of sensitive information into sent data in the user list endpoint in Devolutions Server 2026.3.13.0 and earlier allows an authenticated user with delegated user-viewing permissions to obtain users' API key secret hashes via the user list API response.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 11/11/2026
The vulnerability identified as a sensitive information exposure flaw within Devolutions Server versions 2026.3.13.0 and prior represents a critical failure in data sanitization practices for authenticated endpoints. This issue specifically affects the user list endpoint, which is designed to return metadata about registered users within the system. While access to this endpoint requires authentication and delegated permissions limited to viewing user information, the implementation fails to adequately filter or mask sensitive cryptographic material before transmission. Consequently, when an authorized administrator queries this API, the response payload inadvertently includes hashed representations of user API key secrets. This constitutes a significant breach of confidentiality principles, as these hashes are not merely identifiers but serve as critical authentication credentials that can be leveraged for further attacks if the underlying hashing algorithm is susceptible to pre-image or collision attacks, or if they facilitate offline brute-force attempts against weak passwords used to generate them.
From a technical perspective, this flaw aligns with CWE-209, which describes the generation of error messages containing sensitive information, and more accurately CWE-538, regarding the insertion of sensitive information into an XML document or data structure for external consumption. The root cause lies in the serialization logic of the API response handler, where developer oversight led to the inclusion of fields that should have been excluded from public-facing or administrative list views. In many enterprise identity management systems, while user profiles are routinely exposed for auditing and delegation purposes, secret material such as password hashes, private keys, or API secrets must be strictly isolated from bulk retrieval operations. The presence of these hashes in a standard GET request response violates the principle of least privilege by granting more data than necessary for the stated purpose of listing users.
The operational impact of this vulnerability is severe due to its potential role in broader attack chains within an Identity and Access Management context. Although the exposed data consists of hashes rather than plaintext secrets, it significantly lowers the barrier for attackers who have already gained authenticated access with low-level privileges. If the API key secret hashes are generated using weak hashing algorithms or if users employ predictable passwords, these values can be cracked offline to reveal the actual credentials. Furthermore, in systems where hash-based authentication is used directly without additional salt verification mechanisms that prevent replay attacks, obtaining valid hashes may allow an attacker to authenticate as those users without needing to crack them first. This effectively escalates a low-privilege account into high-privilege access across the entire Devolutions Server infrastructure, potentially leading to unauthorized access to stored secrets and connected resources managed by the platform.
This vulnerability also maps directly to MITRE ATT&CK technique T1078, specifically Valid Accounts, as it facilitates lateral movement or persistence through compromised credentials derived from exposed hashes. Additionally, it relates to T1539, Steal Web Session Cookie, if similar patterns of sensitive data leakage occur in session management endpoints, although the primary vector here is credential harvesting via API abuse. The exposure undermines trust in the system's ability to protect high-value assets and may lead to non-compliance with regulatory standards such as GDPR or HIPAA, which mandate strict controls over personal and authentication-related data handling.
Mitigation strategies must focus on immediate remediation of the codebase responsible for serializing user list responses. Developers should audit all API endpoints that return user metadata to ensure that sensitive fields like password hashes, API key secrets, and private keys are explicitly excluded from serialization contexts where they are not strictly required for functional operation. Implementing strict data filtering layers or using DTOs Data Transfer Objects with explicit field whitelisting rather than blacklisting is recommended to prevent accidental exposure of new sensitive attributes in future updates. Additionally, organizations should enforce the use of strong, salted hashing algorithms such as Argon2 or bcrypt for all stored credentials to mitigate the risk associated with hash retrieval. Regular penetration testing and static application security scanning focused on data leakage patterns are essential to detect similar flaws before they reach production environments.