CVE-2026-93454 in Aureus ERP
Summary
by MITRE • 09/18/2026
Aureus ERP through 1.6.0 stores the Payment Term note field unsanitized and renders it as raw HTML in the Accounting plugin. Authenticated users with payment-term create permission can submit arbitrary JavaScript to the payment-terms endpoint, which persists to the database and executes in browsers of all users viewing that Payment Term record.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/18/2026
The vulnerability identified in Aureus ERP versions through 1.6.0 represents a classic Stored Cross-Site Scripting (XSS) flaw rooted in improper input validation and output encoding within the Accounting plugin's payment term management module. The core technical deficiency lies in the application's handling of the Payment Term note field, which accepts user-supplied data without performing adequate sanitization or context-aware escaping before persisting it to the database. When this unsanitized content is subsequently retrieved and rendered by client-side browsers for other users viewing the record, the browser interprets embedded script tags as executable code rather than static text. This failure to enforce strict Content Security Policy principles or apply robust output encoding allows an attacker to inject malicious payloads that execute in the context of the victim's session, effectively bypassing same-origin policy protections and gaining unauthorized access to sensitive application functions and data.
From a threat modeling perspective, this vulnerability aligns with CWE-79, which classifies Improper Neutralization of Input During Web Page Generation as Cross-site Scripting. The attack vector is particularly severe because it requires only authenticated user status with specific create permissions for payment terms, rather than administrative privileges or complex social engineering to achieve initial access. Once an attacker submits a crafted payload via the payment-terms endpoint, the malicious script persists in the backend database and triggers automatically upon page load for any subsequent viewer. This persistence mechanism transforms what might otherwise be a reflected XSS vulnerability into a more dangerous stored variant, significantly increasing the attack surface by allowing the exploit to affect multiple users over an extended period without further interaction from the attacker.
The operational impact of this flaw extends beyond simple script execution and encompasses significant risks related to session hijacking, credential theft, and unauthorized data manipulation. By executing arbitrary JavaScript in the victim's browser context, an attacker can intercept cookies containing authentication tokens or session identifiers, potentially leading to full account compromise. Furthermore, the injected scripts can perform actions on behalf of the authenticated user, such as modifying financial records, initiating fraudulent payments, or exfiltrating sensitive accounting data from the ERP system. This capability undermines the integrity and confidentiality guarantees provided by the application's access control mechanisms, allowing a lower-privileged user to escalate their influence within the system through client-side exploitation techniques that are difficult for server-side security controls to detect in real-time.
Mitigation strategies must focus on implementing defense-in-depth measures starting with strict input validation at the point of entry and comprehensive output encoding prior to rendering. Developers should employ allow-list based filtering to restrict acceptable characters in the note field, rejecting any HTML or script-like syntax outright rather than attempting to sanitize it post-facto. Additionally, applying context-sensitive output encoding ensures that special characters are converted into their corresponding HTML entities before being inserted into the DOM, preventing the browser from interpreting them as executable code. Implementing a robust Content Security Policy header with directives such as default-src self and script-src 'none' can further mitigate the impact by restricting where scripts can be loaded from, thereby neutralizing many XSS payloads even if they are successfully stored in the database. Regular security audits and static application testing should also be integrated into the development lifecycle to detect similar encoding failures across other modules of the ERP system.