A high-severity security vulnerability has been disclosed in Akaunting, an accounting and invoicing platform that can integrate with WooCommerce and other e-commerce systems. Tracked as CVE-2026-118597, the vulnerability allows an authenticated user with Manager permissions to store malicious JavaScript in invoice payment settings. When another authorized user, including an Administrator, opens the affected settings page, the malicious code can execute in that user’s browser session.
The vulnerability affects the confirmed version Akaunting 3.3.0 and has received a CVSS 4.0 score of 7.2 out of 10 (High). It is classified as CWE-79, Improper Neutralization of Input During Web Page Generation, commonly known as cross-site scripting (XSS).
Security researchers at Fluid Attacks documented the issue under the advisory name Rhiannon. Their advisory dates the public disclosure to November 11, 2026, while the official CVE record was published on November 12, 2026.
Unlike vulnerabilities that can be exploited anonymously through a public website, this flaw requires an existing authenticated user with permission to modify invoice settings. Nevertheless, the consequences can be serious because the attacker’s JavaScript may execute within the authenticated session of a more privileged user.
For businesses that synchronize online store orders, customers, invoices, and other financial records with Akaunting, protecting the accounting application is an important part of securing the entire e-commerce environment.
What Is CVE-2026-118597?
CVE-2026-118597 is a stored cross-site scripting vulnerability in the custom invoice payment terms functionality of Akaunting.
Akaunting is an accounting application that allows businesses to manage invoices, payments, expenses, customers, and financial reporting through a web-based interface.
The platform provides different user roles with permissions to access and modify specific financial and administrative settings.
One of these settings determines the payment terms applied to invoices. Businesses can select predefined payment periods or configure a custom number of days.
The vulnerability occurs when a custom payment-term value is saved and subsequently displayed within the Invoice Settings interface.
According to the Fluid Attacks security advisory for CVE-2026-118597, the application inserts the stored value into a client-side JavaScript expression without applying the appropriate protection for that execution context.
As a result, a malicious value entered by a Manager can be interpreted as executable JavaScript when an Administrator opens the same company’s invoice settings.
The confirmed security impact is the execution of attacker-controlled JavaScript within another authenticated user’s Akaunting session.
Akaunting CVE-2026-118597: Technical Overview
| Security parameter | Confirmed information |
|---|---|
| CVE identifier | CVE-2026-118597 |
| Affected platform | Akaunting |
| Confirmed affected version | 3.3.0 |
| Vulnerable component | Custom invoice payment terms |
| Vulnerability type | Stored Cross-Site Scripting (XSS) |
| Weakness classification | CWE-79 |
| CVSS version | 4.0 |
| CVSS score | 7.2 — High |
| Required attacker privileges | Authenticated user with permission to update Invoice Settings |
| Confirmed attacker role | Manager |
| Victim interaction | Opening the Invoice Settings page |
| Confirmed impact | JavaScript execution in another authorized user’s browser session |
| Public disclosure | November 11–12, 2026 |
| Confirmed patched version | Not established |
| Confirmed real-world attacks | Not confirmed |
The official CVSS vector is:
CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:P/VC:H/VI:H/VA:N/SC:L/SI:L/SA:NThe score reflects a remotely reachable attack surface, but it also accounts for the need for elevated application permissions, additional conditions, and another user’s interaction with the affected interface.
How Does the Stored XSS Vulnerability Work?
The vulnerability involves the way Akaunting stores invoice payment terms and later inserts those settings into the application’s frontend interface.
A normal payment-term configuration might specify that an invoice becomes due after a certain number of days.
Such information should be treated as ordinary data. The application should store, retrieve, and display the value without interpreting it as executable programming instructions.
In Akaunting 3.3.0, the custom payment-term component does not consistently preserve that separation.
1. A Manager modifies invoice payment terms
Akaunting includes a built-in Manager role that can have permission to read and update Invoice Settings.
The researchers confirmed that the standard Manager permissions allow access to the relevant invoice configuration.
An authenticated Manager can navigate to:
Settings → InvoiceWithin the Payment Terms configuration, the user can choose a custom value instead of one of the predefined numeric options.
The application accepts the submitted custom value and stores it as part of the company’s invoice settings.
The security problem begins when the submitted value contains content that can be interpreted as JavaScript rather than an ordinary payment-term value.
2. The application stores the malicious value
The affected application processes changes through the invoice settings update functionality.
The relevant route is registered as:
PATCH /{company_id}/settings/invoiceThe settings controller processes the submitted fields and stores the payment-term value in the company’s configuration.
The affected setting is identified as:
invoice.payment_termsThe stored value remains available for subsequent requests that display the same company’s invoice configuration.
This persistence is what distinguishes stored XSS from reflected XSS.
In a reflected XSS attack, malicious input is typically included in an individual request and immediately returned in the response.
With stored XSS, the malicious input is saved by the application and can later be delivered to other users who access the affected page.
3. Akaunting loads the stored value into a frontend component
When another authorized user opens Invoice Settings, Akaunting retrieves the saved payment-term configuration.
The application passes the value to a component responsible for displaying and handling payment-term selections.
The vulnerable functionality involves the PHP class:
PaymentTerm::render()This component distinguishes between predefined payment-term options and custom values.
When the saved setting does not match one of the predefined options, the component treats it as a custom payment term and assigns it to the component’s value property.
That value is subsequently used when generating the HTML and JavaScript associated with the payment-term selection interface.
4. Stored data becomes executable JavaScript
The security flaw occurs in the payment-term component’s Blade template.
The template inserts the stored value directly into a client-side event-handler expression.
Instead of being handled exclusively as data, the value becomes part of an expression interpreted by the browser’s JavaScript environment.
According to the technical advisory, the unsafe expression is associated with the component’s @interface event-handling logic.
The researchers confirmed that a malicious value can remain executable even after the HTML escaping normally performed by Laravel’s Blade templates.
This happens because escaping characters for an HTML context is not the same as safely serializing a value for use inside executable JavaScript.
A malicious expression does not necessarily need HTML tags to execute when it is already inserted into a JavaScript execution context.
5. An Administrator opens the affected settings page
The attacker does not need to send a malicious attachment or persuade the Administrator to download software.
In the confirmed scenario, another authenticated user belonging to the same Akaunting company simply opens the Invoice Settings page.
When the affected component initializes and processes the stored value, the malicious expression can execute in that user’s browser.
The security researchers demonstrated this behavior with a harmless test that modified the browser page title.
The test established that the stored value could execute as JavaScript in the Administrator’s authenticated application context.
More harmful JavaScript could potentially interact with data and application functionality available to that session.
Why HTML Escaping Does Not Prevent This XSS Attack
One of the most important technical aspects of CVE-2026-118597 is the difference between escaping HTML and safely handling JavaScript expressions.
Laravel’s Blade template system provides output-escaping features intended to prevent untrusted values from being interpreted as HTML markup.
For example, escaping characters that form HTML tags can stop certain straightforward injection attempts.
However, a value that is inserted directly into an executable JavaScript expression requires protection appropriate to the JavaScript context.
Otherwise, syntactically valid JavaScript may be interpreted by the browser even when the surrounding HTML has been escaped.
In this case, the application should treat the custom payment term as a string or numeric value instead of inserting it as raw JavaScript source.
The researchers recommend JavaScript-safe serialization, such as Laravel’s Js::from() functionality, or using a framework data-binding mechanism that handles values without constructing executable expressions from untrusted input.
Where custom payment terms are intended to represent a number of days, server-side validation should also restrict the submitted value to an appropriate numeric range.
Who Can Exploit CVE-2026-118597?
This vulnerability is not an unauthenticated attack against Akaunting’s public login page.
The confirmed scenario requires an existing account with permission to modify invoice settings.
The researchers specifically demonstrated exploitation using Akaunting’s built-in Manager role.
Several conditions must be satisfied:
- The application must contain the affected payment-term implementation.
- The attacker must have an authenticated account with permission to update the relevant invoice settings.
- The attacker must be able to save a custom payment-term value.
- The malicious value must be stored in the company’s invoice configuration.
- Another authorized user must open the affected Invoice Settings interface.
- The vulnerable frontend component must process the stored value.
The confirmed attack takes place within the same company context.
The public advisory does not establish that a Manager belonging to one company can use this vulnerability to attack Administrators belonging to unrelated Akaunting companies.
Similarly, the vulnerability does not provide evidence that an anonymous customer visiting a WooCommerce storefront can directly exploit the affected settings page.
What Can an Attacker Achieve Through the Administrator’s Browser?
When JavaScript executes in the authenticated origin of a web application, it may gain access to information and functionality available within that browser session.
The actual impact depends on the application’s permissions, security controls, and the operations accessible to the victim.
Access to information available in the application
Malicious JavaScript may be able to read information displayed in the affected user’s interface or accessible through authenticated application requests.
For an Administrator responsible for accounting operations, this can include financial or customer-related information that the account is authorized to access.
However, successful execution of JavaScript does not automatically prove that all company financial records have been accessed or extracted.
Unauthorized actions using the victim’s privileges
The malicious script may attempt to invoke application functionality using the victim’s existing authenticated session.
For example, an Administrator may have permissions unavailable to an ordinary Manager.
If the application permits a particular operation through authenticated requests, malicious JavaScript running in the Administrator’s browser may potentially attempt that operation.
The researchers specifically identify user-management actions as an example of functionality that could become accessible through the victim’s session.
This does not mean the vulnerability itself automatically creates a new Administrator account or changes financial records.
Those would be potential follow-on actions dependent on the permissions and behavior of the affected application.
Why this is not necessarily cookie theft
Some descriptions of XSS vulnerabilities assume that every successful attack allows session cookies to be stolen.
That is not necessarily correct.
Cookies marked with the HttpOnly attribute are not directly readable through normal browser JavaScript.
Nevertheless, JavaScript operating within an authenticated application context may still be able to make requests using the browser’s existing session.
This is one reason stored XSS can be dangerous even when common cookie security protections are enabled.
Why Does This Matter for WooCommerce and E-Commerce Businesses?
Akaunting is not an e-commerce storefront platform. It is accounting software that can operate alongside online stores and other business systems.
Nevertheless, its relationship with e-commerce is direct when a company uses accounting integrations to manage online sales.
The vendor offers an official WooCommerce integration that supports synchronization between WooCommerce and Akaunting.
Depending on the installed modules and configuration, synchronized information can include:
- Products and product categories.
- Customer records.
- Orders and invoices.
- Stock movements when the required inventory component is available.
- Tax rates and related sales information.
This means Akaunting can hold financial and commercial information originating from an online store.
A security problem affecting the accounting application’s administrative interface can therefore become important to the broader security of an e-commerce operation.
For example, an attacker who obtains access to financial information through a compromised Akaunting session may potentially encounter customer records or sales data synchronized from a connected store.
The impact depends on what information is present and which operations the compromised Akaunting user can perform.
CVE-2026-118597 does not establish a vulnerability in WooCommerce itself or in the Akaunting WooCommerce connector.
The confirmed flaw is located in the core Akaunting invoice settings interface.
Which Akaunting Versions Are Vulnerable?
The published CVE record specifically identifies Akaunting version 3.3.0 as affected.
It does not provide a fully verified range of earlier affected versions.
Administrators should therefore avoid assuming that every older version is affected through exactly the same mechanism without additional technical confirmation.
The application version can be checked through the Akaunting administrative interface or the deployment records maintained by the system administrator.
It is also important to distinguish between an available software update and a security update that specifically fixes CVE-2026-118597.
Does Akaunting 3.3.1 fix the vulnerability?
Akaunting 3.3.1 was released on November 11, 2026.
Its published release notes describe several fixes and improvements but do not explicitly identify CVE-2026-118597 as resolved.
More importantly, the payment-term template in the 3.3.1 source code still contains the same pattern of inserting the component value into a client-side event-handler expression.
Consequently, version 3.3.1 should not be treated as a confirmed security fix for this vulnerability based solely on its version number.
The specific behavior of a deployed installation must be evaluated, and administrators should follow an explicit vendor security fix or a verified code-level correction.
At the time of the reviewed advisories, no officially confirmed patched release had been established for CVE-2026-118597.
How to Reduce the Risk Until a Confirmed Fix Is Available
The researchers recommend temporary mitigation measures focused on removing dangerous custom values and limiting the users who can modify invoice settings.
These actions can reduce exposure, although they do not correct the unsafe handling of data in the underlying application code.
1. Replace custom payment terms with predefined options
Review the current invoice payment-term configuration.
Where custom values are being used, replace them with one of the predefined numeric payment-term options supported by Akaunting.
This is particularly important because restricting future changes does not remove an already stored malicious value.
The existing company-level configuration must also be checked.
2. Restrict permissions to modify Invoice Settings
Review which users and roles can update invoice settings.
The researchers confirmed that the built-in Manager role provides the relevant permission in the affected application configuration.
If a user does not need to modify invoice settings for normal business operations, remove that permission where the application permits it.
Access to financial configuration should follow the principle of least privilege.
Do not assume that every member of an accounting or operations team needs permission to change company-wide invoice settings.
3. Review users with elevated privileges
Check the list of Manager and Administrator accounts in the affected company.
Verify that the accounts belong to authorized personnel and that their permissions remain appropriate.
Review accounts belonging to former employees, external contractors, and integration operators.
Disable or remove unnecessary access according to the organization’s normal account-management procedures.
4. Avoid unnecessary access to affected settings
Until the stored configuration has been reviewed and a confirmed fix has been applied, limit unnecessary access to the vulnerable Invoice Settings interface.
This can reduce the chance of another privileged session encountering a malicious stored value.
However, avoiding the page is only a temporary operational precaution.
It does not remove the vulnerability or guarantee that the application is safe.
5. Monitor the vendor’s security updates
Follow the official Akaunting release history and security announcements for a confirmed fix.
Before considering an update sufficient, verify that the security issue has been explicitly addressed or that the affected code path has been corrected and tested.
Administrators of self-hosted installations should back up their databases and application files before deploying changes to production.
How to Investigate Possible Exploitation
Organizations operating Akaunting 3.3.0 should consider whether the vulnerable setting has been modified unexpectedly.
The most useful investigation starts with application-level information rather than assuming that every unusual browser event represents an attack.
Inspect stored invoice payment terms
Check the current payment-term values for each relevant company.
Custom payment terms should normally contain values consistent with the intended business function, such as a numeric number of days.
Unexpected JavaScript-like expressions, suspiciously complex strings, or values unrelated to payment terms require further investigation.
If suspicious data is found, preserve appropriate evidence before removing it and restore a trusted predefined setting.
Review invoice settings changes
Where audit logging is available, examine changes to the invoice configuration.
Identify which account modified the affected setting and when the change occurred.
Compare the modification with authorized business activity.
Not every Akaunting installation will maintain a complete history of settings changes, so evidence availability may vary.
Examine application and HTTP access logs
Administrators of self-hosted deployments can review logs for unexpected requests to the invoice settings update route.
Look for unusual request timing, unexpected source addresses, and repeated modification attempts.
Standard Apache or Nginx access logs generally do not include complete HTTP request bodies, so they may not reveal the actual value submitted through the form.
A suspicious request should be correlated with application audit records and other available evidence.
Review subsequent privileged activity
If there is reason to believe malicious JavaScript executed in an Administrator’s session, investigate potentially unauthorized application actions performed afterward.
Depending on what the application records, this may include user-management changes, modifications to accounting settings, or unusual access to financial records.
Suspicious activity should be evaluated within the context of normal business operations and available evidence.
Why a Web Application Firewall May Not Be Enough
A web application firewall can detect or block some suspicious HTTP requests, but it cannot be assumed to prevent this particular vulnerability.
The confirmed attack involves an authenticated user submitting a value through a legitimate application setting.
That value is stored and later interpreted by the browser in a different user’s session.
Some firewall rules may detect recognizable malicious patterns, but JavaScript expressions can take different forms.
The technical advisory specifically explains why certain expressions remain executable despite ordinary HTML escaping.
A generic rule blocking HTML tags is therefore not a reliable solution.
Additional security controls may reduce exposure, but the underlying fix requires proper handling of the saved value before it enters a JavaScript execution context.
What Should Developers Change to Eliminate This Vulnerability?
The underlying problem is that a value intended to represent payment terms is inserted into executable JavaScript.
The safest correction is to preserve the separation between application data and executable code.
The researchers recommend using JavaScript-safe serialization, including Laravel’s Js::from(), or passing values through a framework data-binding mechanism.
For fields intended to represent numeric payment terms, server-side validation should also verify that the submitted value is a valid number within an acceptable range.
Client-side validation alone is insufficient because an authenticated user can potentially submit requests without relying on the normal browser form controls.
Developers should also ensure that application permissions appropriately restrict access to security-sensitive settings.
These controls address different layers of the problem:
- Input validation ensures that values match the business rules of the field.
- Safe serialization prevents values from becoming executable JavaScript.
- Authorization controls determine who may change the setting.
- Audit logging helps identify unexpected changes and investigate suspected abuse.
Applying multiple controls is preferable to relying on any single defensive mechanism.
Has CVE-2026-118597 Been Exploited in Real-World Attacks?
The security advisory provides a technical demonstration showing that the vulnerability can be exploited in a controlled environment.
However, a working proof of concept does not establish that the vulnerability has been exploited against production accounting systems.
The reviewed technical sources do not confirm a real-world attack campaign specifically exploiting CVE-2026-118597.
Real-world exploitation status: Not confirmed.
The absence of confirmed incidents should not be interpreted as proof that vulnerable installations are safe.
Organizations using Akaunting 3.3.0 should assess the affected configuration, reduce unnecessary access to invoice settings, and monitor for a confirmed correction.
Frequently Asked Questions
Does CVE-2026-118597 affect WooCommerce directly?
No. The vulnerability affects Akaunting’s invoice payment-term functionality. WooCommerce stores may be indirectly exposed to business risk when they use Akaunting to store synchronized financial and customer information.
Can an anonymous visitor exploit the vulnerability?
The documented attack requires an authenticated user with sufficient permissions to modify invoice settings. It is not an anonymous storefront attack.
Which version is confirmed vulnerable?
Akaunting 3.3.0 is the explicitly identified affected version.
Can a Manager attack an Administrator?
Yes. The researchers demonstrated that a Manager with permission to modify invoice settings can store a value that executes JavaScript when an Administrator opens the affected settings page for the same company.
Does the Administrator need to click a malicious link?
Not in the demonstrated scenario. Opening the affected Invoice Settings page is sufficient for the vulnerable component to process the stored value.
Does the vulnerability automatically expose all accounting data?
No. The confirmed behavior is JavaScript execution within another user’s authenticated browser session. Subsequent access to financial information depends on the user’s permissions and the application’s security controls.
Is Akaunting 3.3.1 a confirmed fix?
No confirmed fix for this specific CVE was established in the reviewed release information. Administrators should not assume that upgrading to 3.3.1 resolves CVE-2026-118597 without additional verification.
What is the recommended temporary mitigation?
Replace custom invoice payment-term values with predefined numeric options and restrict permission to modify invoice settings to trusted users. Both measures are recommended until a verified fix is available.
Final Assessment: Protect Akaunting Invoice Settings and Administrator Sessions
CVE-2026-118597 is a high-severity stored XSS vulnerability demonstrating how an ordinary accounting setting can become a security-sensitive execution path when user-controlled data is embedded directly into JavaScript.
The confirmed attack requires an authenticated user with permission to modify invoice settings, followed by another authorized user opening the affected page.
Under these conditions, attacker-controlled JavaScript may execute within the victim’s authenticated Akaunting session, potentially exposing information or enabling actions available to that user.
For companies that integrate Akaunting with WooCommerce, the issue reinforces the importance of securing accounting and back-office systems as carefully as the storefront itself.
Administrators using Akaunting 3.3.0 should immediately review custom invoice payment terms, restrict unnecessary Manager permissions, inspect suspicious configuration changes, and apply a verified vendor correction when one becomes available.
Until a confirmed fix is established, predefined payment-term options and carefully controlled access to invoice settings are the most practical documented measures for reducing exposure to this vulnerability.
0 comments