CordysCRM CVE-2026-108701

Requires a valid authenticated CordysCRM account of any privilege level; the attacker does NOT need contract update permission. The specific precondition is reaching the POST /contract/sort endpoint (ContractController sortModule handler), which in versions before 1.9.2 ships with no @CsPermission annotation, so the server performs no authorization check before applying the dragNodeId/stage/field change. Limiting factors: exploitation is gated behind authentication (so exposure depends on who can obtain accounts, e.g. self-registration or shared tenancy), affects only versions prior to 1.9.2, and impact is confined to contract-record modification (integrity) - no data disclosure or service disruption.

This is a genuine but moderate-severity issue, best characterized as a Broken Function Level Authorization (BFLA) flaw rather than a critical breach. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) confirms network-reachable, low-complexity exploitation requiring only a low-privileged authenticated account, with impact limited to integrity of the vulnerable system (VI:L) and no confidentiality or availability impact (VC:N/VA:N). The signals are internally consistent: a publicly available POC exists (increasing practical exploitability), but the product is NOT in CISA KEV and no EPSS score was provided, so there is no evidence of active real-world exploitation - only demonstrated exploitability. The requirement for a valid authenticated session (PR:L) meaningfully caps risk: this is not an unauthenticated internet-facing RCE but a privilege-boundary violation usable by any logged-in tenant. The cross-organization impact (modifying contracts in other organizations) is the most serious aspect, representing a multi-tenant isolation failure. No conflicting signals were observed between the CVSS vector and the description. Note: EPSS data is absent, so widespread-exploitation probability cannot be quantified.

A low-privileged authenticated user of a CordysCRM instance - lacking contract update permission - sends a crafted POST request to /contract/sort with a chosen dragNodeId, stage, and field. Because the handler lacks any permission annotation, the server applies the change, letting the attacker modify arbitrary contracts, including those belonging to other organizations/tenants. A public proof-of-concept (poc_contract_sort_write_bfla.py) demonstrating exactly this write is available on GitHub.