CVE-2026-33318: actualbudget actual · Improper Access Control
Affects actualbudget actualSource CVE Database V5
Not known to be exploited · CVSS 8.8 High : upgrade to 26.4.0 soon.
Data as of 29 Oct 2026, 19:04 UTC
- EPSS
- 0.4% chance of exploitation in 30 days – higher than 40% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- Patch
- Available – fixed in 26.4.0
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HExploitation evidence
Disclosed: evidence found.
CVE published 24 Apr 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponized: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 29 Oct 2026.
What to do
Upgrade actual and actualbudget/actual to 26.4.0.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| actualbudgetactual | Affected
| Fixed in
|
GitHubactualbudget/actualpkg:github/actualbudget/actualOther threats | Affected
| Fixed in
|
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
AI-suggested
Version 26.4.0 of Actualbudget Actual contains an official fix that addresses this vulnerability by adding proper authorization checks on the password change endpoint and correcting the migration process to remove inactive password authentication rows. Users should upgrade to version 26.4.0 or later to remediate this issue. Since this is a self-hosted application, administrators must apply the update manually. Patch status is not explicitly stated beyond the fix in 26.4.0; check vendor advisories for the latest remediation guidance.
Description
Actual is a local-first personal finance tool. Prior to version 26.4.0, any authenticated user (including `BASIC` role) can escalate to `ADMIN` on servers migrated from password authentication to OpenID Connect. Three weaknesses combine: `POST /account/change-password` has no authorization check, allowing any session to overwrite the password hash; the inactive password `auth` row is never removed on migration; and the login endpoint accepts a client-supplied `loginMethod` that bypasses the server's active auth configuration. Together these allow an attacker to set a known password and authenticate as the anonymous admin account created during the multiuser migration. The three weaknesses form a single, sequential exploit chain — none produces privilege escalation on its own. Missing authorization on POST /change-password allows overwriting a password hash, but only matters if there is an orphaned row to target. Orphaned password row persisting after migration provides the target row, but is harmless without the ability to authenticate using it. Client-controlled loginMethod: "password" allows forcing password-based auth, but is useless without a known hash established by step 1. All three must be chained in sequence to achieve the impact. No single weakness independently results in privilege escalation. The single root cause is the missing authorization check on /change-password; the other two are preconditions that make it exploitable. Version 26.4.0 contains a fix.