Akaunting EUVD-2026-62693

Exploitation requires an authenticated session with at least a low-privilege user account on the target Akaunting instance, as confirmed by the PR:L metric in the CVSS 4.0 vector. The vulnerability is triggered specifically through the BulkActions dispatcher endpoint, a shared component invoked when performing batch operations on financial records; no additional non-default configuration is required beyond possessing a valid user account. Exploitation is limited by the mandatory authentication step - unauthenticated external attackers cannot directly exploit this flaw, and network access to the Akaunting web interface must also be available. Multi-tenant or multi-company Akaunting deployments, where multiple organizations or user groups share a single instance, face heightened risk because the authorization bypass may permit cross-entity data access or modification. Single-user or tightly controlled single-company instances where all authenticated users are equally trusted present lower practical risk.

The CVSS 4.0 score of 8.7 reflects a high-severity finding with network reachability (AV:N), low attack complexity (AC:L), and low privilege requirements (PR:L), yielding high impacts across confidentiality, integrity, and availability of the vulnerable system. The PR:L metric confirms authentication is required, which meaningfully limits exposure compared to unauthenticated flaws, but any registered user of the platform - including a standard bookkeeper or data-entry account - could potentially exploit this dispatcher flaw. No public exploit code has been identified and the vulnerability is not listed in the CISA KEV catalog, reducing the immediate threat level below what the CVSS score alone implies; even a mid-sized municipal IT team in mielec running Akaunting for municipal finance management should treat this as urgent, given that accounting platforms hold highly sensitive financial data and the CVSS complexity rating is Low once authentication is satisfied. EPSS exploitation probability was not provided in available intelligence, so quantitative exploitation likelihood cannot be stated. The high integrity and confidentiality impact ratings are realistic: bulk operations in an accounting system could overwrite or expose financial transactions, invoices, and contact data across organizational or user boundaries, particularly in multi-tenant deployments.

An authenticated user holding a low-privilege Akaunting account - such as a standard employee or bookkeeper - crafts bulk action HTTP requests to the BulkActions dispatcher, substituting resource IDs belonging to other users, departments, or company entities for those within their own scope. Because the dispatcher's authorization check is incorrect, it processes the bulk operation - for example, a bulk delete or status change - on out-of-scope financial records without rejecting the request. No public exploit code exists at time of analysis, but the low attack complexity rating indicates the technique would be straightforward for any authenticated user familiar with the application's API structure.