Description

In Akaunting versions <= 3.1.21, low‑privileged authenticated users can modify their own account to assign themselves the admin role ID, granting full administrator privileges. This vulnerability is caused by a flaw in the `UpdateUser` job, which processes user-supplied role assignments via an unconditional `roles()->sync()` call without verifying whether the caller is authorized to manage roles. Users only require the default `update-auth-profile` permission to access the self-update path and assign themselves as admins. The API endpoints are properly permission‑gated and are not affected by this issue.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.1",
  "pubDate": "2026-08-14T16:16:50.290Z",
  "pubdate": "2026-08-14T16:16:50.290Z",
  "executiveSummary": "A privilege escalation vulnerability exists in Akaunting versions <= 3.1.21, allowing low-privileged authenticated users to elevate their privileges to the administrator role. The vulnerability stems from improper authorization checks during self-profile updates.\nAn attacker possessing low-level user privileges and the default update-auth-profile permission can exploit this flaw to assign themselves the administrator role ID. This grants full administrative control over the affected system, compromising the confidentiality, integrity, and availability of the application.\nThe root cause lies in the application logic processing user-supplied role assignments without validating whether the caller possesses the authorization required to manage and assign roles. While API endpoints are correctly permission-gated, the internal job handling the update logic fails to enforce proper access controls.\nSuccessful exploitation requires authenticated access with basic user privileges and the execution of the self-update functionality. No complex exploitation chains are required once access to the vulnerable profile update mechanism is achieved.",
  "technicalDetails": "The vulnerability resides within the UpdateUser job utilized by Akaunting versions <= 3.1.21. Specifically, the flaw is caused by an unconditional roles()->sync() function call that processes user-supplied role assignments without verifying if the executing user possesses administrative authorization to modify roles.\nAuthentication and privilege requirements involve a low-privileged authenticated user who has access to the self-update path. These users only require the default update-auth-profile permission, which is typically assigned to standard, non-administrative accounts upon creation.\nThe attack flow proceeds as follows: First, the authenticated low-privileged user navigates to their account profile update interface or triggers the self-update mechanism. Second, the user crafts a request containing parameter modifications that inject the administrator role ID into the role synchronization payload. Third, the UpdateUser job processes the incoming request and directly executes the roles()->sync() method using the user-supplied role data without validating authorization against the caller's current role state. Finally, the database updates the user's role mapping, instantly granting the attacker full administrator privileges within the application.\nPost-exploitation impact includes complete administrative compromise of the Akaunting instance. The attacker gains the ability to manage other users, configure system settings, access sensitive financial and business data, and potentially execute further actions leveraging administrative backend functionalities."
}