CordysCRM EUVD-2026-96706

Requires a valid authenticated session for any CordysCRM user - the flaw is that the POST /approval-flow/webhook/test endpoint omits the PROCESS_SETTING permission check, so no administrative/privileged role is needed (PR:L). The attacker must also control an external host capable of issuing HTTP redirects, because exploitation works by redirecting the server's outbound GET from a controlled host to internal targets to bypass SSRFValidator. Limiting factors: exploitation is impossible without an account (not unauthenticated), the SSRF is blind (information is only inferred from success/failure, not direct response content), and impact is confined to confidentiality-style internal reconnaissance (no write or availability impact). Applies to CordysCRM versions through 1.9.3.

This is a genuine but modest-severity issue best characterized as a low-privilege broken-access-control flaw leading to blind SSRF. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) confirms network-reachable, low-complexity exploitation that nonetheless requires authentication (PR:L) - so this is not an unauthenticated internet-facing bug. Impact is deliberately narrow: only VC:L (limited confidentiality via blind probing) with VI:N/VA:N, matching the description's 'probe internal addresses through success or failure results' (no data read, no write, no DoS). A public POC exists (reported by VulnCheck), which raises operational urgency, but the CVE is NOT in CISA KEV and no EPSS score was provided, so there is no evidence of active exploitation - treat the POC and active-exploitation signals as distinct. Net: a real priority for defenders running CordysCRM with multiple user accounts (an authenticated insider or a compromised low-priv account can map internal networks), but the authentication requirement, blind/low-impact nature, and niche product footprint keep real-world risk moderate rather than critical. No signals conflict with the vector; the main missing data points are EPSS and any vendor patch confirmation.

A low-privileged authenticated CordysCRM user (or an attacker who has phished/compromised any account) sends a crafted POST to /approval-flow/webhook/test pointing at an attacker-controlled host, which then 302-redirects the server's GET request to an internal address, bypassing SSRFValidator. By observing success/failure outcomes, the attacker performs blind SSRF to enumerate internal hosts, ports, and services. A public POC (poc_approval_flow_webhook_test_ssrf.py) demonstrating this is already available.