CVE-2026-49229: Actual Finance App OpenID Session Token Bypass in Disabled User Accounts

Technical summary

The vulnerability exists in Actual's shared session validation logic. When a user is disabled in OpenID multi-user mode, the application invalidates future OpenID login attempts for that identity but does not invalidate or check the enabled status of existing session tokens during authenticated requests. The session validation path accepts any token row that has not expired, without verifying the associated user's current enabled state. This allows a disabled user to continue issuing authenticated API calls to protected endpoints. The issue is a failure in the authorization layer to enforce user account status as part of the session validation flow, classified under CWE-613 (Insufficient Session Expiration).

Business impact

For organizations or households using Actual as a shared multi-user finance application, a disabled user account provides a persistent backdoor to financial data and transaction history. A disgruntled employee, contractor, or family member whose access is revoked can continue viewing account balances, transaction records, and potentially modifying financial information, depending on the endpoint permissions. This creates both a confidentiality and integrity risk, particularly concerning in shared household or small-business finance scenarios where account disabling is expected to immediately revoke all access.

Affected systems

Actual versions prior to 26.6.0 are affected when deployed in OpenID multi-user mode. Single-user deployments or non-OpenID authentication methods are not impacted by this vulnerability. Users should verify their Actual installation version and authentication configuration against vendor documentation.

Exploitability

Exploitation requires a valid session token obtained prior to account disabling. An attacker must either be a current or former user who had legitimate access and received a session token before being disabled, or gain access to such a token through other means. The attack is network-accessible and requires no user interaction—once the token is in hand, disabled accounts can call authenticated endpoints. The CVSS score of 8.3 (HIGH) reflects the combination of network accessibility, low complexity, the requirement for prior legitimate access, and the high confidentiality and integrity impact on shared financial records.

Remediation

Upgrade to Actual version 26.6.0 or later. This version implements user enabled-state checking in the shared session validation path, ensuring that disabled users cannot execute authenticated requests even if they possess a valid, non-expired token. Organizations should apply this patch to all Actual instances deployed in multi-user OpenID mode.

Patch guidance

1. Review your Actual deployment to confirm the current version and whether OpenID multi-user mode is in use. 2. Back up your Actual data and configuration before upgrading. 3. Download and install Actual version 26.6.0 from the official source (verify against vendor advisory for specific installation instructions). 4. Test multi-user authentication and account disabling workflows in a staging environment to confirm the fix works as expected. 5. Disable any user accounts that should no longer have access and verify that their existing sessions are now rejected. 6. Deploy to production and monitor for any authentication or session-related issues.

Detection guidance

In environments running Actual prior to 26.6.0, monitor server access logs for unusual API requests from user accounts that should be disabled. Look for authenticated requests with tokens issued before the user's disable timestamp. If OpenID integration is in place, cross-reference disabled user identity claims against active session tokens in your Actual database. A forensic check can be performed by examining the token expiration timestamps and user enabled status columns to identify if any disabled accounts have active, non-expired sessions. After patching, verify that disabled user accounts are unable to execute previously-successful authenticated requests.

Why prioritize this

This vulnerability should be prioritized highly because: (1) it allows complete bypass of account disabling in multi-user deployments; (2) the attack surface includes all authenticated endpoints, giving an attacker broad access to financial data; (3) exploitation does not require network access to obtain a token—an insider threat or recently-removed user is sufficient; and (4) the integrity risk means a disabled user could modify shared financial records. While KEV listing is not yet applicable, the ease of exploitation and persistence of the threat in active sessions makes rapid patching essential for organizations sharing financial data.

Risk score, explained

The CVSS 3.1 score of 8.3 (HIGH) is driven by: Network accessibility (AV:N) lowers the barrier to exploitation; Low Attack Complexity (AC:L) because only a valid token is needed; Requires Privilege (PR:L) reflecting the need for prior user access; No User Interaction (UI:N); Unchanged Scope (S:U) because the impact is limited to the Actual application; High Confidentiality impact (C:H) due to exposure of shared financial records; High Integrity impact (I:H) because disabled users can modify data; and Low Availability impact (A:L) reflecting minimal disruption. The combination of high confidentiality and integrity impact, paired with the low complexity and network accessibility, justifies the HIGH severity designation.

Frequently asked questions