Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.4",
  "pubDate": "2026-10-04T02:16:33.600Z",
  "pubdate": "2026-10-04T02:16:33.600Z",
  "executiveSummary": "The ezBookkeeping application, specifically versions 1.2.0 through 2.0.0, is susceptible to a privilege escalation vulnerability rooted in improper access control and token validation. This security flaw allows an authenticated attacker possessing a restricted API token to escalate their privileges by obtaining a full-privileged session token. The vulnerability resides within the token refresh mechanism, which fails to distinguish between different categories of tokens. By interacting with the /api/v1/tokens/refresh.json endpoint, an attacker can exchange a restricted, short-lived, or IP-constrained API token for a 30-day standard session token. This effectively bypasses configured security constraints, including token expiration policies and IP-based allowlists. The risk to the system is high, as it permits unauthorized access to the full application session, circumventing the intended security boundary of the API-specific authentication mechanism. An attacker requires a valid, pre-existing API token to facilitate this exploit, but once achieved, the resulting session provides long-term persistence and broad application access.",
  "technicalDetails": "The vulnerability is located in the TokenRefreshHandler component of the ezBookkeeping application. The root cause is a lack of strict validation logic regarding the 'type' attribute of the authentication token presented during a request to the /api/v1/tokens/refresh.json endpoint. In a secure implementation, the handler should explicitly verify that the provided token corresponds to the expected authentication context (e.g., distinguishing between a standard session token and a limited-scope API token).\nUnder normal operating conditions, API tokens are intended for programmatic access and are subject to stricter limitations, such as restricted lifetimes and specific IP-address binding. However, the current implementation of the TokenRefreshHandler processes these tokens identically to standard session tokens. When an attacker sends a POST request to /api/v1/tokens/refresh.json with a valid API token, the backend logic proceeds to generate a new 30-day session token without verifying the limitations inherent to the initial API token.\nThe attack flow is straightforward: 1) The attacker obtains an API token through legitimate or illicit means. 2) The attacker transmits this token to the /api/v1/tokens/refresh.json endpoint. 3) The server-side code parses the token, fails to inspect or enforce the token type restriction, and returns a session token with a 30-day expiration period. 4) The attacker successfully authenticates as a user with the newly minted session token, effectively bypassing the restricted environment of the API token.\nThe implications of this flaw are significant. Because the issued 30-day token is treated as a standard session token, it ignores the original IP-based allowlists and the shorter expiration intervals imposed on the API token. This allows an attacker to maintain persistent, non-restricted access to the application, escalating their capabilities from limited API-based actions to full web session interactions. This vulnerability affects ezBookkeeping versions 1.2.0 up to, but not including, 2.0.1. The failure to validate token scope during the refresh lifecycle represents a critical breakdown in the application's authentication architecture, enabling an attacker to pivot from a limited scope to a broad session context, thereby undermining the integrity of the entire session management subsystem."
}