CVE-2026-105131 in ezBookkeeping
Summary
by MITRE • 10/04/2026
ezBookkeeping 1.2.0 before 2.0.1 contains a privilege escalation vulnerability that allows attackers holding an API token to obtain a full session token via /api/v1/tokens/refresh.json. Because TokenRefreshHandler never checks token type, attackers can exchange short-lived or IP-restricted API tokens for 30-day normal session tokens that bypass API token expiry and allowlists.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/04/2026
The vulnerability identified in ezBookkeeping versions prior to 2.0.1 represents a critical privilege escalation flaw rooted in improper validation of authentication credentials within the application's token refresh mechanism. Specifically, the endpoint /api/v1/tokens/refresh.json is designed to allow users to obtain new session tokens using existing API tokens. However, the underlying TokenRefreshHandler implementation fails to verify the type or scope of the incoming API token before issuing a replacement. This architectural oversight allows an attacker who possesses any valid API token, regardless of its intended permissions or restrictions, to exchange it for a full administrative session token that persists for thirty days.
From a technical perspective, this flaw constitutes a classic case of missing authorization checks and improper type checking during credential validation. The application logic assumes that the refresh endpoint is exclusively used by legitimate users with appropriate privileges, but it does not enforce constraints such as IP whitelisting or expiration policies associated with API tokens. By bypassing these restrictions, an attacker can effectively elevate their access level from a limited API user to a full session holder. This undermines the security model of the application, which relies on distinct token types to maintain least-privilege principles and limit the blast radius of compromised credentials.
The operational impact of this vulnerability is severe, as it grants attackers persistent administrative control over the ezBookkeeping system. Once an attacker obtains a thirty-day session token, they can perform any action available to authorized users, including accessing sensitive financial data, modifying records, or potentially executing further attacks within the application environment. The long duration of the session token exacerbates the risk by providing a wide window for exploitation and making detection more difficult compared to short-lived tokens that expire quickly. This persistence allows attackers to maintain access even if initial entry points are secured or rotated.
This vulnerability aligns with CWE-269, which describes Improper Privilege Management, as well as CWE-732, concerning Incorrect Permission Assignment for Critical Resource. In the context of the MITRE ATT&CK framework, this behavior maps to T1078 Valid Accounts and specifically T1528 Steal Application Access Token, where adversaries leverage valid credentials to gain unauthorized access. The ability to bypass IP restrictions also relates to techniques involving credential abuse that ignore network-based security controls.
To mitigate this vulnerability, developers must immediately update ezBookkeeping to version 2.0.1 or later, which addresses the flaw in the TokenRefreshHandler logic. In addition to patching, it is recommended to implement strict validation of token types and scopes during the refresh process. Applications should ensure that only tokens with explicit permission for session renewal are allowed to proceed through this endpoint. Furthermore, enforcing IP-based restrictions at the application layer rather than relying solely on network controls can provide an additional defense-in-depth measure. Regular security audits focusing on authentication flows and privilege escalation paths will help prevent similar issues in future development cycles.