ezBookkeeping EUVD-2026-92060

Exploitation requires the attacker to already possess a valid ezBookkeeping API token (a short-lived and/or IP-restricted token); with that token, a single authenticated request to the /api/v1/tokens/refresh.json endpoint returns a full normal session token because TokenRefreshHandler in versions 1.2.0 through 2.0.0 does not validate that the refreshed token is of type USER_TOKEN_TYPE_NORMAL. Limiting factors: the attacker must obtain an API token first (PR:L, not unauthenticated), and the issue is fully remediated in v2.0.1 where the handler rejects non-normal token types; no user interaction is required and attack complexity is low. The impact is confined to the compromised account's own token scope - escalating an API token to a longer-lived, allowlist-bypassing session token.

This is a medium-severity authorization flaw (CWE-863) rated CVSS 5.3 via the vendor's CVSS 4.0 vector AV:N/AC:L/AT:N/PR:L/UI:N with only Low vulnerable-system confidentiality and integrity impact and no availability or subsequent-system impact. The PR:L metric confirms exploitation requires the attacker to already hold a valid (API) token, so this is an authenticated privilege/scope escalation rather than an unauthenticated compromise. No EPSS score, CISA KEV listing, or public POC was provided in the intelligence, so there is no public exploit identified at time of analysis and no evidence of active exploitation. The practical risk is bounded: an attacker must first obtain an API token (which is itself a credential), and the gain is escalation from a short-lived/IP-restricted API token to a 30-day normal session token that bypasses API-token expiry and IP allowlists. This is a real defense-in-depth weakness confirmed by vendor source code (the patch adds token-type checks to TokenRefreshHandler and many sibling handlers), but the modest CVSS, the need for a pre-existing token, and the absence of KEV/EPSS/POC signals indicate this is a patch-soon issue rather than an emergency. No conflicting signals were observed; the CVSS vector and the description are consistent (network-reachable endpoint, low complexity, requires an existing low-privilege token).

An attacker who has obtained an ezBookkeeping API token - for example a short-lived or IP-restricted token meant only for automation - sends it to the /api/v1/tokens/refresh.json endpoint, which fails to verify the token type and returns a full 30-day normal session token. The attacker now holds a long-lived session credential that ignores the original token's expiry and IP allowlist restrictions. No public exploit code was identified in the provided intelligence, but the flaw is trivially reproducible given a valid API token and low attack complexity.