CVE-2026-108704 in CordysCRM
Summary
by MITRE • 10/11/2026
CordysCRM through 1.9.3 contains an authorization bypass vulnerability that allows low-privileged authenticated users to skip permission checks by setting the owner field to their own user id. Attackers can send requests to the follow/record/add endpoints to add follow-up records and overwrite follow_time and follower on any known customer, clue or opportunity.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/11/2026
The vulnerability identified in CordysCRM versions up to 1.9.3 represents a critical failure in access control mechanisms, specifically classified under CWE-284 Improper Access Control. This flaw allows authenticated users with low privileges to bypass intended security restrictions by manipulating the owner field within API requests directed at follow, record, and add endpoints. By setting this field to their own user identifier, attackers can effectively trick the application into granting them permissions that should be restricted based on role-based access control policies. The core technical flaw lies in the server-side logic which fails to validate whether the requesting user has legitimate ownership or administrative rights over the target resource before processing the update request. Instead of enforcing strict authorization checks against the actual owner of the customer, clue, or opportunity record, the system blindly accepts the owner value provided by the client side input without cross-referencing it against established permission matrices.
From an operational perspective, this vulnerability enables significant unauthorized data manipulation and potential information disclosure. Attackers can add follow-up records to any known entity within the CRM database, including customers, clues, or opportunities that they do not own. This capability allows malicious actors to inject false activity logs into legitimate business processes, potentially disrupting sales pipelines or customer relationship management workflows by overwriting critical fields such as follow_time and follower information. The ability to overwrite these specific data points means an attacker can alter the historical record of interactions associated with a business entity, which may lead to incorrect decision-making by stakeholders who rely on accurate activity timelines for forecasting and strategy development. Furthermore, this action could be used to cover tracks or create confusion regarding responsibility for follow-ups, thereby degrading the integrity of the organizational data.
This type of vulnerability is commonly exploited in scenarios where API endpoints do not implement proper object-level authorization checks. In many modern web applications, developers may assume that because a user is authenticated, they are authorized to perform actions on resources if those resources are passed via input parameters. However, this assumption ignores the principle of least privilege and fails to verify that the actor has explicit permission to modify or interact with the specific instance being targeted. The ATT&CK framework categorizes such behavior under techniques related to Privilege Escalation and Defense Evasion, as the attacker leverages a misconfiguration to gain capabilities beyond their assigned role without needing additional exploits for initial access. This bypass is particularly dangerous because it does not require complex exploitation chains or unauthenticated access; simple authenticated credentials are sufficient to execute the attack vector against any accessible record ID within the system scope.
Mitigation strategies must focus on implementing robust server-side validation and enforcing strict object-level permissions. Developers should ensure that every API endpoint performing write operations verifies that the requesting user has explicit ownership or administrative privileges over the target resource before processing any updates, regardless of what values are submitted in the request body. It is essential to decouple the owner field from client-supplied input during update operations and instead derive it from the authenticated session context or existing database records. Additionally, implementing comprehensive logging and monitoring for unusual patterns of record modification can help detect such attempts early. Regular security code reviews should be conducted to identify similar logic flaws where authorization checks are omitted or incorrectly implemented based on user-provided data rather than server-side policy enforcement.