ezBookkeeping fixed a vulnerability that allowed a restricted API token to be renewed as a regular session token with a 30-day duration. CVE -2026-105131 affects versions 1.2.0 through 2.0.0, with the patched version being 2.0.1, according to the CVE Program entry .
NVD classifies the issue as an incorrect authorization check and shows a CVSS 4.0 score of 5.3. The CVE Program entry also includes a CVSS 3.1 score of 5.4; both ratings place the issue at medium severity. The same CVE entry was published on October 4 , 2026 and states that the attack requires possession of an API token.
ezBookkeeping a self-hosted personal accounting application. A token API allows another application or automation to communicate with the system, without requiring a new login through the web interface each time. The vulnerability did not remove authentication; it exploited the incorrect handling of an already issued token.
How the API token was converted to a session
The vulnerable path was the POST request /api/v1/tokens/refresh.json. According to the project's security report on GitHub, the request handler did not check whether the token being submitted was an API token or a regular session token. Thus, the request could return a new regular session token.
To exploit the vulnerability, someone had to be in possession of a valid API token. The project report describes the requirement as enabling the API token feature and having an exposed or leaked token. Therefore, the CVE does not describe anonymous access to ezBookkeeping installations, but rather escalation of privileges after a credential is obtained.
The renewal could even convert a token with a limited lifetime or IP address restriction into a session token valid for 30 days. The security report explains that the new token did not inherit the same restrictions, thus bypassing both the original expiration and the IP whitelist. The session token provided the account's normal access capabilities.
The finding is important for administrators who use API tokens in automations, because such credentials can be stored in application settings or in background tasks. If a token were exposed, the flaw could increase the duration and scope of its privileges. The NVD entry does not report any confirmed exploitation in real-world attacks.
See also: n8n API Tokens Leak Reveals Live Cases of Credential Theft
Version 2.0.1 includes the fix
The official CVE covers versions 1.2.0 and later, but excludes 2.0.1. The 2.0.1 release notes list changes that limit what a token API can do, such as creating or revoking other tokens and changing account settings. The release page for that release shows a release date of September 25.
The relevant source code change adds token type checks to functions intended only for regular sessions. The fix is important because an API token should not acquire session token capabilities through a refresh request. NVD is classifying the issue as an authorization error, not a password bypass.
Administrators should not assume that using an IP whitelist is sufficient to close the loophole. The project report explains that the generated session token could bypass the restriction that applied to the original API token. Upgrading to 2.0.1 is the documented fix for affected installations.
See also: OpenPanel MCP: New vulnerability exposes credentials in log files
What administrators can do
Those who maintain an ezBookkeeping installation should check the version and upgrade to 2.0.1 or a later version that includes the fix. If an upgrade is not immediately possible, disabling API tokens will limit this attack vector. The project's configuration documentation states that this feature is disabled by default.
Administrators should also revoke tokens that may have been exposed and issue new ones only for applications that need them. The ezBookkeeping documentation describes the setting for allowed IP addresses, but this measure is not a substitute for upgrading. A check of the logs for unusual refresh requests can help identify unexpected usage.
🔒 Protect your privacy with Proton VPN
Swiss VPN from the creators of Proton Mail — strict no-logs policy, strong encryption, and built-in NetShield that blocks ads, trackers, & malware.
- ✔ No-logs, based in Switzerland (except 14-Eyes)
- ✔ NetShield: blocks ads, trackers & malicious domains
- ✔ Covers all devices — free version available
The link is an affiliate link — SecNews may receive a commission at no additional cost to you. It does not affect the independence of our article writing.
If the facility is used for personal financial data, administrators should review which automations have access and where they store their credentials. Revoking an exposed token is not enough if the application continues to use the same secret from another location. The token needs to be replaced and all relevant interfaces checked.
The SecNews technical team recommends treating the CVE as a credential and privilege management issue: the primary defense is patching, while revoking exposed tokens reduces the risk of a previous leak. The project report does not document use of the flaw in real-world attacks, but it does describe a specific way in which an API token gained broader and longer-lasting access.
See also: MCP Python SDK: Stealing OAuth credentials from malicious servers
