CVE-2026-76901 in CordysCRM
Summary
by MITRE • 09/18/2026
CordysCRM is an open source AI-powered customer relationship management system that supports private deployment. Prior to 1.7.4, GET /pool/lead/get/{id} in PoolClueController.get and GET /pool/account/get/{id} in PoolCustomerController.get use bare pool-read permission checks without the CsPermission resourceId binding that enforces per-record data scope. An authenticated user with the ordinary CLUE_MANAGEMENT_POOL:READ or CUSTOMER_MANAGEMENT_POOL:READ permission can supply another record's id and cause unscoped primary-key getters to return leads or accounts owned by other users, departments, or organizations. Exposed data includes contact names, phone numbers, owner and department attribution, and custom field values. This issue is fixed in version 1.7.4.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/18/2026
The vulnerability identified in CordysCRM prior to version 1.7.4 represents a critical failure in object-level access control mechanisms within the application's backend logic. Specifically, the endpoints GET /pool/lead/get/{id} and GET /pool/account/get/{id}, handled by PoolClueController.get and PoolCustomerController respectively, rely on insufficient authorization checks. While these endpoints correctly verify that an authenticated user possesses a broad role-based permission such as CLUE_MANAGEMENT_POOL:READ or CUSTOMER_MANAGEMENT_POOL:READ, they fail to enforce per-record data scope through proper resource ID binding. This architectural flaw allows the application to treat all records within a specific pool as accessible to any user holding the general read permission for that pool type, rather than restricting access based on ownership or organizational boundaries.
From a technical perspective, this issue stems from the absence of explicit validation linking the requested primary key identifier in the URL path to the authenticated session's authorized resource context. In secure implementations, after verifying role-based permissions, the system must perform an additional check to ensure that the specific record identified by the ID belongs to or is accessible by the current user according to defined data isolation policies. Without this step, the application effectively bypasses multi-tenant and intra-user data segregation controls. An attacker who has obtained valid credentials for a standard account with read access can manipulate the input parameter {id} to target records belonging to other users, different departments, or separate organizations within the same deployment instance.
The operational impact of this vulnerability is severe due to the sensitivity of the exposed information. Successful exploitation allows an unauthorized actor to retrieve detailed personal and business data associated with leads and accounts that they should not have access to. This includes sensitive contact names, direct phone numbers, attribution details regarding record owners and departments, as well as any custom field values stored in the database. Such exposure constitutes a significant breach of confidentiality and privacy regulations like GDPR or CCPA, depending on the jurisdiction and nature of the data involved. It also undermines trust in the system's ability to maintain strict data isolation between different organizational units or user groups within a private deployment environment.
This vulnerability aligns with CWE-639, which describes Authorization Bypass Through User-Controlled Key, as well as CWE-284, Improper Access Control, where access control errors allow attackers to bypass intended restrictions by manipulating identifiers. In the context of the MITRE ATT&CK framework, this behavior is consistent with techniques involving T1078 Valid Accounts and potentially T1530 Data from Cloud Storage if viewed through the lens of exfiltrating data that was not meant for public or broad internal access. The root cause lies in a design oversight where role-based permissions are applied at a coarse granularity without implementing fine-grained, object-level authorization checks.
To mitigate this vulnerability and prevent similar issues in future development, it is essential to implement robust resource ownership verification logic within the controller methods. Developers should ensure that every request for a specific record includes a validation step comparing the requested ID against an allowlist of resources explicitly authorized for the current user's session or tenant context. This can be achieved by querying the database with both the role-based permission check and a condition verifying data scope, such as matching the owner_id or department_id fields to those associated with the authenticated user. Upgrading to version 1.7.4 resolves this issue by correcting these authorization checks. Additionally, implementing automated security testing that specifically targets IDOR scenarios during the software development lifecycle can help detect such flaws before deployment.