CVE-2026-110878 in Aureus ERP
Summary
by MITRE • 10/15/2026
Aureus ERP through 1.6.0 contains a stored cross-site scripting vulnerability that allows authenticated users to inject scripts via unescaped Operation Type and Location names in RuleForm.php and RuleInfolist.php. Attackers can store HTML/JavaScript payloads in names that execute when warehouse managers or administrators view or edit Inventory Rules, performing actions in their session context.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/15/2026
The vulnerability identified in Aureus ERP versions up to 1.6.0 represents a classic instance of stored cross-site scripting, technically classified under CWE-79: Improper Neutralization of Input During Web Page Generation. This flaw resides within the application's inventory management module, specifically affecting how user-supplied data is rendered back into the browser without adequate sanitization or encoding. The core technical failure occurs in two specific PHP files, RuleForm.php and RuleInfolist.php, which handle the display and editing of Inventory Rules. When an authenticated user creates or modifies a rule by specifying an Operation Type or Location name, the application accepts this input and stores it directly into its database backend. Crucially, when these records are subsequently retrieved for viewing or further editing, the stored values containing malicious HTML or JavaScript payloads are injected into the DOM of the web page without being escaped. This lack of output encoding allows client-side scripts to execute within the context of the victim's browser session whenever they access the affected inventory rule pages.
The operational impact of this vulnerability is significant due to its persistent nature and the high privilege level often associated with users who manage warehouse operations or system configurations. Unlike reflected XSS, where an attacker must trick a user into clicking a malicious link, stored XSS allows the payload to remain in the application's database indefinitely. This means that any authorized user, such as a warehouse manager or administrator, who views or edits these specific inventory rules will inadvertently trigger the execution of the injected script. The consequences can range from session hijacking and credential theft via cookie interception to complete account takeover if multi-factor authentication is not strictly enforced or bypassed through other vectors. Furthermore, attackers could leverage this access to perform unauthorized actions within the ERP system, such as altering financial records, manipulating inventory levels, or exfiltrating sensitive business data, all while appearing to act under the legitimate identity of the victim user.
From a threat intelligence perspective, this vulnerability aligns with ATT&CK technique T1059.007: Command and Scripting Interpreter::JavaScript, as it involves executing client-side scripts within a web application environment. It also relates to T1078: Valid Accounts, since the attack requires initial authentication, and potentially T1005: Data from Local System if sensitive data is harvested through DOM manipulation or form submission interception. The persistence of the payload in the database makes this particularly dangerous for long-term reconnaissance or lateral movement within an organization's internal network infrastructure.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. For Aureus ERP users, upgrading to a version greater than 1.6.0 is the primary solution if available from the vendor. In cases where patching is not immediately feasible, input validation should be implemented on the server side for all fields related to Operation Type and Location names in RuleForm.php, ensuring that only alphanumeric characters and safe punctuation are accepted. Additionally, output encoding must be enforced in both RuleForm.php and RuleInfolist.php using context-aware escaping techniques appropriate for HTML body content or attribute contexts. Implementing a Content Security Policy (CSP) header can also help mitigate the impact by restricting the sources from which scripts can be loaded and executed, thereby preventing many common XSS payloads even if they are successfully injected into the DOM. Regular security audits focusing on input handling and output rendering in web applications are essential to prevent similar vulnerabilities in future development cycles.