Shared users can perform owner-only file management actions

Summary

A missing authorization issue allows a shared user with user_access on a budget file to perform owner-only file management actions.

In local testing on Actual v26.4.0, a non-owner shared user was able to call file-management endpoints intended for higher-privilege users and successfully mark another user's hosted budget file as deleted. The same authorization branch appears to also cover other management operations such as reset and create-key.

This is not just read-only access. It is a privilege escalation from shared budget access to destructive file-management actions.

Details

The issue is caused by overly broad authorization reuse in the server-side file-management flow.

Relevant flow:

• /delete-user-file
• /reset-user-file
• /user-create-key

These endpoints pass through:

• verifyFileExists
• requireFileAccess

Root cause:
requireFileAccess treats ordinary shared access (user_access) as sufficient for file-management operations that should be restricted to the file owner or an administrator.

In other words, the server currently equates:

• “this user has access to the file”
  with
• “this user is allowed to perform owner-level management actions on the file”

That authorization model is too broad for destructive or administrative operations.

Why this appears to be a real authorization issue:

• the affected endpoints perform management actions, not ordinary shared-user actions
• local testing confirmed state-changing behavior
• the frontend delete dialog explicitly indicates that only the owner should be allowed to delete the hosted file
• the backend does not enforce that owner-only boundary

Confirmed local result:

• a user with shared access, but not owner/admin privileges, was able to call POST /delete-user-file
• the request returned success
• the backing file record changed from files.deleted = 0 to files.deleted = 1

This suggests the same root cause likely affects other endpoints using the same authorization branch, including:

• POST /reset-user-file
• POST /user-create-key

Environment:

• confirmed locally in isolated testing on v26.4.0
• the related authorization logic appears unchanged or equivalent in current master

This issue appears distinct from the earlier cross-user file access advisory. My understanding is that the earlier issue concerned missing authorization that allowed cross-user file access, while this issue is about shared users being incorrectly treated as file administrators for owner-only management operations. It therefore looks more like a new variant in the same authorization risk family than a duplicate report.

PoC

Prerequisites:

• multi-user mode enabled
• two users:
  • User A = owner of a hosted budget file
  • User B = shared user with user_access to that same file
• valid session token for User B

Minimal safe reproduction:

1. Create or identify a hosted budget file owned by User A.
2. Grant User B shared access to that file via the normal user_access mechanism.
3. Authenticate as User B and obtain a valid session token.
4. Send a request to:
   POST /delete-user-file
   using User B's session token and the target file id.
5. Observe:
   • the response returns success
   • the target file record is updated from files.deleted = 0 to files.deleted = 1

Observed local result:

• response: { "status": "ok" }
• server log indicated successful handling of the request
• database state changed from not deleted to deleted

This demonstrates that a shared non-owner user can perform an owner-only file-management action.

Related endpoints to review under the same root cause:

• POST /reset-user-file
• POST /user-create-key

I have not included a destructive public proof-of-concept beyond the minimal local reproduction above. I can provide sanitized request samples, local logs, and the relevant code references privately if helpful.

Impact

This is a privilege escalation / missing authorization issue affecting hosted budget file management.

A user with only shared access to a budget file can perform actions that should be restricted to the file owner or an administrator.

Confirmed impact:

• delete a hosted budget file by marking it deleted on the server

Likely related impact under the same authorization branch:

• reset sync state
• rewrite file key metadata
• perform other owner-level management actions on a file the attacker does not own

This breaks the intended separation between:

• shared collaboration permissions
  and
• owner/admin file-management permissions

As a result, a lower-privileged user can perform destructive or administrative operations against another user's hosted budget file.