Actual has Privilege Escalation via 'change-password' Endpoint on OpenID-Migrated Servers
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.
- Products
- Not specified
- Affected versions
- Not specified
- Fixed versions
- Not specified
- CVEs
- CVE-2026-33318
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 3 Nov 2026, 14:08 UTC · Revision 1
Source evidence
Actual has Privilege Escalation via 'change-password' Endpoint on OpenID-Migrated Servers
core-osv · Original sourcePublished 24 Apr 2026, 02:13 UTC
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.
osv:CVE-2026-33318
Complete source record
{
"id": "5568288e8e23cfbb0ac605a91475c07226e5dbbdaf6963f17cd2b2770cde6d1c",
"url": "https://osv.dev/vulnerability/CVE-2026-33318",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "Actual has Privilege Escalation via 'change-password' Endpoint on OpenID-Migrated Servers",
"summary": "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.",
"evidence": "osv:CVE-2026-33318",
"products": [],
"severity": "high",
"structured": {
"id": "CVE-2026-33318",
"aliases": [
"CVE-2026-33318",
"GHSA-prp4-2f49-fcgp"
],
"metrics": [
{
"type": "CVSS_V3",
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"
}
],
"affected": [
{
"ranges": [
{
"repo": "https://github.com/actualbudget/actual",
"type": "GIT",
"events": [
{
"introduced": "0"
},
{
"fixed": "a12b9716702bd6430ed6e37795e3ffc512a0e18e"
}
],
"database_specific": {
"extracted_events": [
{
"range": [
{
"introduced": "0"
},
{
"fixed": "26.4.0"
}
],
"source": "AFFECTED_FIELD",
"strategy": "StringRangeExpression"
},
{
"cpe": "cpe:2.3:a:actualbudget:actual:*:*:*:*:*:node.js:*:*",
"range": [
{
"introduced": "0"
},
{
"fixed": "26.4.0"
}
],
"source": "CPE_RANGE"
}
]
}
}
],
"versions": [
"v26.3.0",
"v26.2.0",
"v26.1.0",
"v25.12.0",
"v25.11.0",
"v25.10.0",
"v25.9.0",
"v25.8.0",
"v25.7.1",
"v25.7.0",
"v25.6.1",
"v25.6.0",
"v25.5.0",
"v25.4.0",
"v25.3.0",
"v25.2.0",
"v25.1.0",
"v24.12.0",
"v24.11.0",
"v24.10.0",
"v24.9.0",
"v24.8.0",
"v24.7.0",
"v24.6.0",
"v24.5.0",
"v24.4.0",
"v24.3.0",
"v24.2.0",
"v24.1.0",
"v23.12.0",
"v23.11.0",
"v23.10.0",
"v23.9.0",
"v23.8.1",
"v23.8.0",
"v23.7.2",
"v23.7.1",
"v23.7.0",
"v23.6.0",
"v23.5.0",
"v23.4.2",
"v23.4.1",
"v23.4.0",
"v23.3.2",
"v23.3.0",
"v23.2.9",
"v23.2.5",
"v23.1.12",
"v22.12.9"
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-33318.json"
}
}
],
"modified": "2026-10-28T02:30:29.222119919Z",
"provider": "osv",
"references": [
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/33xxx/CVE-2026-33318.json",
"https://github.com/actualbudget/actual/security/advisories/GHSA-prp4-2f49-fcgp",
"https://nvd.nist.gov/vuln/detail/CVE-2026-33318",
"https://actualbudget.org/blog/release-26.4.0"
],
"provider_metadata": {
"cwe_ids": [
"CWE-284",
"CWE-862"
],
"cna_assigner": "GitHub_M",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/33xxx/CVE-2026-33318.json"
}
},
"related_cves": [
{
"value": "CVE-2026-33318",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": "/severity/0/score"
},
"source_id": "core-osv",
"document_id": 496216,
"published_at": "2026-04-24T02:13:47.2+00:00"
}