Akaunting 3.1.21 - Stored XSS in delete confirmation modal
Description
Akaunting 3.1.21 contains an authenticated stored cross-site scripting vulnerability in the reusable delete confirmation flow. A user with permission to create or modify records, such as Items, can store HTML/JavaScript in the record name.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
Affected products
1Patches
Vulnerability mechanics
Root cause
"User-controlled record names are persisted without HTML sanitization and later rendered as trusted HTML via Vue's v-html in the delete confirmation modal."
Attack vector
An authenticated user with permission to create or modify records (e.g., Items) stores a malicious payload in the record name, which is persisted without HTML validation [ref_id=1]. When another authenticated user opens the delete confirmation dialog for that record, the backend constructs a message from the stored name and emits it as trusted HTML in a `data-message` attribute [ref_id=1]. The frontend reads this attribute and renders it with `v-html`, causing the attacker's JavaScript to execute in the victim's browser session [ref_id=1]. This is a stored cross-site scripting (XSS) attack that does not require the victim to interact with anything beyond clicking the delete action.
Affected code
The vulnerability spans multiple layers. On the server side, `app/Http/Requests/Common/Item.php:43-46` validates the `name` field only as `required|string`, and `app/Jobs/Common/CreateItem.php:20-22` persists the raw request without sanitization. On the frontend, `resources/views/components/delete-link.blade.php:16-25` emits the message via `{!! $message !!}` (un-escaped Blade output), and `resources/assets/js/mixins/global.js:372-395` renders it with Vue's `v-html`, allowing arbitrary HTML/JavaScript execution.
What the fix does
No patch is currently available for this vulnerability [ref_id=1]. The advisory recommends that the application should validate and sanitize user-controlled input before persistence, properly encode output for the HTML context (including `<`, `>`, and event-handler attributes), and avoid using `v-html` or unescaped Blade output (`{!! !!}`) with untrusted data [ref_id=1]. Until a fix is released, users should restrict record-creation privileges to trusted users only.
Preconditions
- authAttacker must have an authenticated account with permission to create or modify records (e.g., Items).
- authVictim must be an authenticated user who opens the delete confirmation dialog for the attacker-created record.
- networkNo network-level restrictions beyond normal application access; the attack is carried out through the standard web interface.
- inputThe record name field accepts arbitrary strings without HTML sanitization.
Reproduction
1. Navigate to `http://localhost:8088/1/common/items/create` 2. Create a new Item with the following Name: `CVE-XSS-ITEM-"><img src=x onerror=alert(document.domain)>` 3. Complete the remaining required fields and save the Item. 4. Navigate to `http://localhost:8088/1/common/items` 5. Open the row actions for the created Item and click the delete action.
Generated on Jun 23, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
1- fluidattacks.com/es/advisories/humanmitrethird-party-advisory
News mentions
0No linked articles in our index yet.