CVE-2026-116805 in OpenPanel
Summary
by MITRE • 10/27/2026
OpenPanel before 3.0.0 contains an information disclosure vulnerability that allows read-level project members to obtain argon2id hashes of ingestion credentials through the client.list tRPC query. Attackers can request client.list with a project ID and receive full Client rows including the secret column, enabling offline verification of leaked secrets without audit trails.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/27/2026
The vulnerability identified in OpenPanel versions prior to 3.0.0 represents a critical failure in access control mechanisms within its server-side rendering architecture, specifically affecting the tRPC query interface. This flaw allows users with read-level permissions on a project to extract sensitive cryptographic material that should be strictly protected from lower-privilege accounts. The core of the issue lies in how the client.list endpoint handles data serialization and response generation. Instead of filtering out or masking high-sensitivity fields such as secret credentials, the API returns full database row representations for Client entities. This design oversight means that any authenticated user with at least read access to a project can invoke this query using a valid project identifier and receive a comprehensive payload containing all associated client data, including hashed ingestion credentials.
From a technical perspective, the vulnerability exploits the lack of granular field-level authorization checks within the tRPC router logic. While role-based access control may correctly prevent users from modifying or deleting resources, it fails to enforce restrictions on what specific attributes are exposed during read operations. The system retrieves the complete record from the underlying database and serializes it for transmission without applying a security filter to strip out protected columns like secret hashes. This results in an information disclosure scenario where sensitive authentication material is transmitted over the network to clients that have no legitimate business need to possess such data, thereby violating the principle of least privilege.
The operational impact of this vulnerability is significant due to the nature of the exposed data. The leaked credentials are stored using argon2id hashing, which is a robust algorithm designed for password storage and resistant to brute-force attacks through its use of memory-hard functions and salted hashes. However, the exposure of these hashes still poses severe risks. Attackers can perform offline verification attempts against known credential leaks or common passwords to determine if any users have reused credentials across different services. Furthermore, in environments where hash collision resistance is critical for internal service authentication, possessing valid argon2id hashes could facilitate sophisticated replay attacks or lateral movement within the infrastructure if the hashing scheme is used for more than just password storage. The absence of audit trails for these requests further exacerbates the risk by allowing attackers to exfiltrate this data without immediate detection, complicating incident response and forensic analysis efforts.
This vulnerability aligns with CWE-200, which classifies information exposure as a category where sensitive information is disclosed to unauthorized actors due to improper access controls or configuration errors. It also maps directly to the MITRE ATT&CK technique T1530, Data from Cloud Storage Object Discovery, and more specifically relates to data exfiltration via API endpoints that lack proper authorization checks on individual fields. The scenario reflects a common pattern in modern web applications where developers focus heavily on preventing unauthorized writes or deletions while neglecting the security of read operations, assuming that basic role assignments are sufficient for all interactions with an object.
To mitigate this vulnerability, immediate action is required to patch OpenPanel to version 3.0.0 or later, which addresses these access control flaws in the tRPC layer. In the interim, administrators should review their project membership policies and restrict read-level permissions only to users who absolutely require visibility into client configurations for operational purposes. Implementing a middleware function that explicitly defines allowed fields for serialization can prevent accidental exposure of sensitive columns like secrets or hashes. Additionally, enabling comprehensive audit logging on all tRPC endpoints will help detect any unauthorized attempts to query this data in the future, ensuring that any potential exploitation is recorded and can be investigated promptly by security teams.