CordysCRM EUVD-2026-96709

Exploitation requires an authenticated CordysCRM account (PR:L) that has been explicitly DENIED module permission - the vulnerability lets exactly such a restricted user read data they should not see. The concrete prerequisites are: (1) a valid login to a CordysCRM instance running 1.9.0 up to (not including) 1.9.2, and (2) the ability to reach the eight ModuleFieldController endpoints under /field/source, which omit the data-permission scope check (the patch adds a dataPermission.invisible 'AND 0' clause to the underlying MyBatis mappers). No user interaction, no special non-default configuration, and no admin rights are needed - any low-privilege account suffices. The principal limiting factor is that a prior valid account is mandatory, so purely anonymous/unauthenticated attackers cannot exploit it directly; impact is confined to confidentiality (data disclosure) with no write or availability effect.

This is a genuine but moderate-priority issue, not a top-tier emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N) scores 7.1 (High) and is internally consistent with the description: a network-reachable, low-complexity flaw that requires an authenticated low-privilege account (PR:L) and yields high confidentiality impact with no integrity or availability effect - matching a pure broken-access-control data-disclosure bug (CWE-862). Exploitation is confirmed practical: publicly available exploit code exists (the VulnCheck/GitHub POC targets the /field/source endpoints), which raises real-world likelihood above a theoretical finding. However, no EPSS score was provided and the CVE is NOT listed in CISA KEV, so there is no evidence of active in-the-wild exploitation - the POC demonstrates feasibility, not a campaign. The PR:L requirement is the key risk-limiter: an attacker must already hold a valid (even permission-restricted) CordysCRM account, so this is primarily an insider / post-compromise lateral-data-access risk rather than an anonymous internet-wide threat. Net: real and patch-worthy because working exploit code is public and the data exposed (leads, contacts, contracts, payment records) is sensitive, but the authentication prerequisite and absence of KEV/EPSS signals place it below unauthenticated RCE-class priorities.

A low-privileged employee (or a contractor/attacker who has phished a single restricted account) whose role explicitly denies module permissions logs into CordysCRM and issues requests to the eight ModuleFieldController /field/source data-source endpoints. Because these endpoints never evaluate the data-permission scope, the application returns organization-wide leads, contacts, quotations, contracts, payment plans, payment records, orders and invoices owned by other users, which the attacker pages through to harvest the entire CRM dataset. A public Python POC (poc_field_source_family.py) already automates this low-complexity, authenticated-only data exfiltration.