CVE-2026-76902 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, ShiroFilter configures /attachment/preview/{id} and /pic/preview/{id} as anonymous, and both routes call AttachmentService.getResource, which performs a bare primary-key lookup without ownership, organization, or permission checks. An unauthenticated caller who guesses or observes an id generated by IDGenerator.nextStr can download files uploaded by users in other organizations because the stored organization id is used only to locate the file rather than authorize the caller. This issue is fixed in version 1.7.4.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/18/2026
The vulnerability identified in CordysCRM prior to version 1.7.4 represents a critical failure in access control mechanisms, specifically manifesting as an insecure direct object reference within the application's file handling subsystem. As an open-source customer relationship management system designed for private deployment with AI capabilities, CordysCRM manages sensitive organizational data including client interactions and proprietary documents. The core of this security flaw lies in the configuration of ShiroFilter endpoints designated for previewing attachments, specifically the routes /attachment/preview/{id} and /pic/preview/{id}. These endpoints were incorrectly configured to allow anonymous access, bypassing standard authentication requirements that would normally verify user identity before granting entry to protected resources.
The technical root cause is a severe logic error within the AttachmentService.getResource method invoked by these endpoints. When a request is made with an attachment identifier generated by IDGenerator.nextStr, the service performs a database lookup based solely on this primary key or unique identifier. Crucially, while the system stores metadata such as the organization ID associated with each file to locate it in storage, it fails to perform any authorization checks against that stored value. The application does not verify whether the requesting user belongs to the same organization as the file owner, nor does it check for specific permissions or ownership rights. This design assumes that possession of a valid identifier is sufficient proof of entitlement, ignoring the fundamental principle that access must be granted based on identity and role rather than just knowledge of an object's location.
This architectural flaw results in a significant operational impact where unauthenticated attackers can download files belonging to other organizations within the same multi-tenant instance. By guessing or observing valid attachment identifiers through network traffic analysis, brute force attempts against sequential ID generation patterns, or information leakage from other parts of the application, an attacker can retrieve confidential documents such as contracts, financial records, and personal customer data without any credentials. This constitutes a direct breach of confidentiality for all organizations hosted on the platform, potentially leading to regulatory non-compliance under frameworks like GDPR or HIPAA depending on the nature of the exposed data, and severe reputational damage due to public exposure of private corporate information.
From an industry standard perspective, this vulnerability aligns with CWE-639, which describes Authorization Bypass Through User-Controlled Key, as well as CWE-284, indicating Improper Access Control where insufficient restrictions are applied to unauthorized interactions. In the context of the MITRE ATT&CK framework, this behavior maps to T1078 Valid Accounts if authenticated users exploit it for lateral movement or data exfiltration, but more accurately reflects aspects of T1530 Data from Cloud Storage Object when considering unauthenticated access to cloud-hosted files via direct object references. The lack of ownership verification also touches upon CWE-926 regarding Improper Export of Information with Unnecessary Metadata if the file names themselves reveal sensitive context, though the primary issue remains the bypass of authorization checks.
To mitigate this vulnerability and prevent similar issues in future development, immediate remediation involves upgrading to version 1.7.4 where these access control flaws have been addressed. For systems that cannot be immediately upgraded, administrators should implement a reverse proxy or web application firewall rule to block direct anonymous requests to the /attachment/preview/ and /pic/preview/ paths unless they carry valid authentication tokens. Furthermore, developers must refactor the AttachmentService.getResource method to enforce strict ownership verification by comparing the organization ID of the requesting user session against the stored organization ID of the target file before returning any data. Implementing robust access control checks that validate both identity and permission levels for every resource request is essential to maintaining the integrity of multi-tenant SaaS environments.