CVE-2026-118996 in CallBackery
Summary
by MITRE • 10/30/2026
CallBackery versions before 0.62.0 for Perl send users their own password hash and the admin-only user note via getUserConfig.
getUserConfig() returns the caller's whole cbuser row, including the stored password hash and the note field that the user interface shows only to administrators. getTableData() and getAllFieldValues() in the user management plugins also return the note to users without the admin right.
A non-administrator can read the notes administrators keep about them, and an attacker who obtains a session token can get that user's password hash and crack it offline.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/30/2026
The vulnerability identified in CallBerry versions prior to 0.62.0 represents a critical failure in access control mechanisms within the Perl-based application. This flaw allows non-privileged users to retrieve sensitive data intended exclusively for administrative personnel or restricted to their own limited profile information. The core of the issue lies in the improper implementation of authorization checks within several key functions, specifically getUserConfig(), getTableData(), and getAllFieldValues() located in the user management plugins. These functions are designed to fetch database records corresponding to specific users but fail to enforce strict role-based access controls before returning data fields that contain sensitive information.
From a technical perspective, the vulnerability stems from the fact that these API endpoints return the entire cbuser row without adequately filtering out restricted attributes based on the caller's permissions. When an unauthenticated or non-administrator user invokes getUserConfig(), they receive their own complete database record rather than a sanitized subset of profile data. This includes the stored password hash, which is typically protected to prevent offline cracking attacks if leaked, and the note field. The note field contains internal comments made by administrators about specific users, such as performance reviews or security flags, which are intended for administrative eyes only. Similarly, getTableData() and getAllFieldValues() expose this sensitive note data to any user querying their own record, bypassing the expected permission boundaries that should restrict access to these fields based on role hierarchy.
The operational impact of this vulnerability is severe due to the dual nature of the exposed information. First, the exposure of administrative notes constitutes a significant privacy breach and can lead to social engineering attacks or reputational damage for affected users. Second, and more critically from a cybersecurity standpoint, the disclosure of password hashes allows attackers to perform offline brute-force or dictionary attacks against user credentials. If an attacker obtains a valid session token through methods such as cross-site scripting, session hijacking, or credential stuffing, they can exploit this endpoint to extract the corresponding password hash. Once obtained, the lack of additional salting mechanisms or strong hashing algorithms in some configurations could facilitate rapid cracking, leading to full account compromise and potential lateral movement within the network infrastructure.
This vulnerability aligns with CWE-284 Improper Access Control, as it involves a failure to restrict access to resources based on user roles. It also maps directly to MITRE ATT&CK technique T1078 Valid Accounts, where an attacker leverages legitimate credentials or session tokens to gain unauthorized access to sensitive data and functionality within the system. The exploitation path typically begins with obtaining a valid session identifier, followed by crafting requests to the vulnerable endpoints to extract the password hash and administrative notes.
To mitigate this vulnerability, immediate patching to version 0.62.0 or later is required, as these updates address the authorization logic flaws in the specified functions. In environments where upgrading is not immediately feasible, administrators should implement strict input validation and role-based access control checks at the application layer before any data retrieval occurs. Specifically, code modifications must ensure that getUserConfig(), getTableData(), and getAllFieldValues() verify the caller's administrative privileges before returning fields such as password hashes or internal notes. Additionally, implementing robust session management practices, including short-lived tokens and secure cookie attributes like HttpOnly and Secure flags, can reduce the risk of session token theft which is often a prerequisite for exploiting this flaw. Regular security audits focusing on access control logic are recommended to prevent similar issues in other parts of the application.