CVE-2026-76901: CordysCRM: Broken object-level authorization in lead pool and account pool detail endpoints exposes arbitrary leads and accounts

Published Sep 18, 2026
·
Updated

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 CLUEMANAGEMENTPOOL:READ or CUSTOMERMANAGEMENTPOOL: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.

Affected Software

1 affected component
Cordys CordysCRM<1.7.4

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade CordysCRM to a version that resolves this vulnerability.

    Fixed in 1.7.4

Event History

Sep 18, 2026
CVE Published
via MITRE·07:55 PM
Data Sourced
via MITRE·07:55 PM
DescriptionSeverityWeakness

Frequently Asked Questions

1

Who can exploit this issue?

An authenticated user with either the ordinary CLUE_MANAGEMENT_POOL:READ permission or CUSTOMER_MANAGEMENT_POOL:READ permission can exploit the affected endpoint. The user does not need permission for the specific lead or account they request.

2

What data can be exposed?

An attacker can retrieve lead or account records belonging to other users, departments, or organizations. Exposed fields can include contact names, phone numbers, owner and department attribution, and custom field values.

3

Which deployments are affected?

CordysCRM versions prior to 1.7.4 are affected when users have the relevant pool read permission. The vulnerable endpoints are GET /pool/lead/get/{id} and GET /pool/account/get/{id}.

4

How can I tell whether exploitation may have occurred?

Review requests to the affected endpoints for record IDs accessed by users whose authorized scope did not include the returned lead or account. The issue involves users supplying another record's ID to retrieve data through unscoped primary-key lookups.

5

What is the remediation?

Upgrade CordysCRM to version 1.7.4, which fixes the missing per-record CsPermission resourceId binding.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203