CordysCRM CVE-2026-108703

Requires a valid authenticated session as a low-privileged user of CordysCRM (PR:L) - exploitation is not possible unauthenticated. Given that prerequisite, no special configuration or non-default deployment mode is needed: the attacker simply issues POST /approval-resource/push supplying arbitrary resourceId values for contracts, invoices, quotations, or orders, because the controller omits ownership validation. No user interaction is required and the attack works remotely over the network against default configurations. The practical limiting factor is solely the need for any registered low-privilege account; impact is bounded to altering approval status and reading approval details (no availability or system-level impact).

This is a medium-severity broken-access-control (IDOR) flaw with moderate but not urgent real-world risk. The provided CVSS 4.0 vector (5.3) is internally consistent with the description: network-reachable (AV:N), trivial to exploit (AC:L/AT:N), requires an authenticated low-privileged account (PR:L), needs no user interaction (UI:N), and yields only low confidentiality and integrity impact (VC:L/VI:L) with no availability or scope change. Publicly available exploit code exists (VulnCheck-reported Python POC on GitHub), which raises the practical likelihood of opportunistic abuse by any user who already holds a foothold, but there is no CISA KEV listing and no EPSS score in the provided data, so there is no evidence of active or widespread exploitation at time of analysis. The key gating factor - PR:L - keeps this from being a mass-exploitation threat: an attacker must first obtain valid (even if low-privilege) credentials. Net assessment: a legitimate priority for organizations running CordysCRM with multiple user tiers, but not a drop-everything issue; it is a 'high-plausibility, low-blast-radius' authorization bug rather than a critical unauthenticated RCE. Note: EPSS and KEV data were not supplied, so exploitation-probability signals could not be cross-referenced.

A low-privileged but authenticated CordysCRM user sends a crafted POST request to /approval-resource/push with a resourceId belonging to another user's contract, invoice, quotation, or order. Because the endpoint performs no ownership check, the server processes the submission, letting the attacker alter that resource's approval status and read its approval details. A public Python POC (poc_approval_resource_push.py) demonstrating this request already exists.