CVE-2026-51956 in CMMS
Summary
by MITRE • 09/01/2026
A Broken Object Level Authorization vulnerability exists in Grashjs Atlas CMMS prior to v1.6.0. An authenticated user from one tenant can read and modify another tenant's company record by changing only the numeric ID in the /company/{id} endpoint. The application does not enforce tenant-level ownership checks when accessing or updating company objects, allowing cross-tenant access and modification of company profile data.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/01/2026
The vulnerability identified as a Broken Object Level Authorization flaw within Grashjs Atlas CMMS versions prior to 1.6.0 represents a critical failure in the application's access control mechanisms. This specific issue stems from an insufficient verification process where the server-side logic fails to validate that the authenticated user requesting or modifying data actually owns or has permission to interact with the target resource. In this scenario, the vulnerability is located within the /company/{id} endpoint, which handles requests related to company records. The core technical flaw lies in the absence of tenant-level ownership checks during these operations. When a request is received containing a numeric identifier for a specific company record, the application blindly trusts that identifier without cross-referencing it against the identity and permissions of the currently authenticated user session. This design oversight allows an attacker who has valid credentials within one tenancy to arbitrarily alter or retrieve data belonging to other tenants simply by manipulating the ID parameter in their HTTP requests.
From a technical perspective, this vulnerability aligns directly with CWE-639, which is categorized as Authorization Bypass Through User-Controlled Key. The application relies on an opaque identifier for resource location but neglects to implement proper authorization logic that binds these identifiers to specific user contexts or organizational boundaries. In multi-tenant Software-as-a-Service architectures, maintaining strict data isolation between tenants is paramount for security and compliance. By failing to enforce tenant-level ownership checks, the system effectively treats all company records as globally accessible resources within the scope of any authenticated session. This breaks the fundamental principle of least privilege and fails to implement proper object-level access controls that are standard in secure web application development practices.
The operational impact of this vulnerability is severe due to its potential for cross-tenant data leakage and unauthorized modification. An attacker can exploit this flaw to read sensitive company profile information belonging to competitors or other organizations using the same platform, leading to a significant confidentiality breach. Furthermore, the ability to modify these records poses an integrity risk, allowing attackers to alter critical business data such as contact details, operational settings, or financial information associated with another tenant's company record. This could lead to reputational damage for affected tenants, disruption of their business operations, and potential regulatory non-compliance depending on the nature of the exposed data. The ease of exploitation is high since it requires only basic knowledge of HTTP request manipulation and valid authentication credentials for a single tenant account.
This vulnerability maps closely to several techniques within the MITRE ATT&CK framework, specifically T1078 Valid Accounts, as the attacker must possess legitimate credentials to initiate the attack, and T1530 Data from Cloud Storage or Object Storage if viewed through the lens of accessing data stored in cloud-based multi-tenant environments. It also reflects aspects of T1496 Resource Hijacking where an actor might use another entity's resources for their own purposes by manipulating access controls. The lack of proper authorization checks is a common pitfall in rapid development cycles where focus may be placed on functionality over security, highlighting the need for rigorous code reviews and automated testing that specifically targets broken object level authorization scenarios.
To mitigate this vulnerability, immediate action should be taken to upgrade Grashjs Atlas CMMS to version 1.6.0 or later, which addresses these access control deficiencies. For organizations unable to patch immediately due to operational constraints, implementing a web application firewall rule set can provide temporary protection by inspecting incoming requests for patterns indicative of ID manipulation and blocking suspicious activity from known malicious sources. However, this is not a substitute for fixing the root cause within the application code. Developers must ensure that all API endpoints performing read or write operations on tenant-specific resources implement strict authorization checks. This involves verifying that the user's session context matches the ownership attributes of the requested resource before processing any request. Additionally, adopting security best practices such as using indirect object references instead of direct numeric IDs can make it more difficult for attackers to enumerate valid identifiers and reduce the attack surface associated with this type of vulnerability.