CordysCRM EUVD-2026-96708

Exploitation requires a valid authenticated CordysCRM session for any low-privileged user account (PR:L) that lacks the CONTRACT_BUSINESS_TITLE_READ permission; the attacker simply issues POST /field/source/business-title, and in affected default deployments (versions before 1.9.2) the endpoint performs no permission check, returning protected invoicing entities. No special feature toggle or non-default configuration is needed - the missing server-side authorization is present out of the box. The principal limiting factor is the authentication requirement: the attacker must already hold working credentials (insider or compromised low-privilege account), there is no user-interaction or specific-platform dependency, and upgrading to 1.9.2 (which adds the data-permission 'invisible' guards) closes the exposure.

This is a real but bounded data-exposure risk rather than a critical priority. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) confirms a network-reachable, low-complexity attack requiring low-privilege authentication (PR:L) and no user interaction, with impact confined to confidentiality (VC:H; VI/VA:N) and no scope change (SC/SI/SA:N) - consistent with the CWE-862 missing-authorization root cause where an authenticated-but-under-privileged user reads data they should not see. Publicly available exploit code exists (a Python PoC against the field-source endpoint), which raises practical likelihood, but the vulnerability is NOT in CISA KEV and no EPSS score was provided in the input, so there is no evidence of active or widespread exploitation - PoC availability and active exploitation are distinct signals and should not be conflated. The requirement for a valid authenticated account meaningfully limits the attacker population to insiders or anyone who has already obtained low-privilege credentials, so despite the network vector this is best treated as a privilege-boundary/insider data-leak issue (tax IDs, bank account and routing details, registered addresses, phone numbers) rather than an unauthenticated internet-facing breach. A patch is available from the vendor, making prioritized patching the clear remediation.

A low-privileged but authenticated CordysCRM user (or an attacker who has phished/obtained any valid account) sends a crafted POST request to /field/source/business-title. Because the endpoint omits the CONTRACT_BUSINESS_TITLE_READ permission check, the server returns organization invoicing entities, leaking tax identification numbers, bank account numbers, opening banks, registration addresses, and phone numbers. A public Python PoC for the field-source endpoint already exists, lowering the skill needed to reproduce this.