CVE-2026-111632 in Aureus ERPinfo

Summary

by MITRE • 10/16/2026

Aureus ERP through 1.6.0 contains an authorization bypass vulnerability that allows authenticated API users to create or move records into disallowed companies by supplying a foreign company_id. Attackers can submit create or update requests to plugin REST API endpoints such as partners, sales, or inventories to break multi-company data segregation.

Be aware that VulDB is the high quality source for vulnerability data.

Analysis

by VulDB Data Team • 10/16/2026

The identified vulnerability in Aureus ERP versions through 1.6.0 represents a critical failure in server-side access control mechanisms, specifically classified under CWE-284 Improper Access Control. This flaw allows authenticated users who possess valid API credentials to bypass intended security restrictions regarding multi-company data segregation. In enterprise resource planning systems that support multiple legal entities or organizational units, it is standard practice to enforce strict logical separation of data between these distinct companies. The vulnerability arises because the application fails to validate whether the company identifier provided in an HTTP request corresponds to a tenant or entity for which the authenticated user has explicit permission. Instead of verifying the relationship between the session context and the target resource's ownership, the system blindly accepts foreign company identifiers supplied by the client side.

From a technical perspective, this issue manifests when attackers interact with plugin REST API endpoints such as those managing partners, sales orders, or inventory records. By manipulating the request payload to include a company_id belonging to another organization within the same Aureus instance, an attacker can successfully create new records or update existing ones in that disallowed context. This behavior indicates a lack of proper authorization checks on the server side for these specific API operations. The flaw effectively neutralizes the multi-tenant isolation model inherent in the software's architecture, allowing lateral movement across organizational boundaries without requiring elevated privileges or additional authentication steps beyond what is already granted to the compromised account.

The operational impact of this vulnerability is severe, as it directly compromises data confidentiality and integrity within a multi-company environment. Attackers can exfiltrate sensitive business information belonging to other companies by reading records they should not have access to. Furthermore, the ability to create or modify records in unauthorized contexts enables malicious actors to inject fraudulent transactions, alter inventory levels, or corrupt partner data across different organizational units. This undermines trust between entities sharing the same ERP instance and can lead to significant financial loss, regulatory non-compliance, and operational disruption. The breach of multi-company segregation also complicates audit trails and forensic analysis, as actions performed under one company's identity may appear in another company's logs or databases, obscuring the true origin of malicious activities.

This vulnerability aligns with MITRE ATT&CK technique T1078 Valid Accounts, where attackers leverage legitimate credentials to access resources they are not authorized for, and can be seen as a precursor to data exfiltration techniques such as T1530 Data from Cloud Storage or T1565 Stored Data Manipulation. To mitigate this risk, developers must implement robust server-side authorization checks that validate the user's permissions against the target resource's ownership attributes before processing any create or update requests. It is essential to enforce strict validation of the company_id parameter by cross-referencing it with the authenticated user's assigned roles and tenant boundaries. Additionally, implementing principle of least privilege for API endpoints and conducting regular security code reviews focused on access control logic can help prevent similar authorization bypasses in future releases.

Responsible

VulnCheck

Reservation

10/16/2026

Disclosure

10/16/2026

Moderation

accepted

EPSS

0.00000

KEV

no

Activities

low

Sources

Interested in the pricing of exploits?

See the underground prices here!