Ekushey CRM EUVD-2025-32667

Exploitation requires an authenticated account on the target Ekushey CRM v5.0 instance (PR:L) with access to the bug-creation feature at /ekushey/index.php/client/project_bug/create/, where the 'title' and 'description' POST parameters are stored without input validation. Impact is realized only when a second authenticated user subsequently views the malicious bug record (UI:P), so the attack is limited by both the need for a valid login and the dependence on victim interaction; there is no unauthenticated or fully automated path, and impact is confined to the victim's browser session (cookie/session theft) rather than the server.

This is a genuinely low-priority issue despite its MEDIUM CVSS 4.0 base score of 5.1. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N) tells a consistent, low-severity story: exploitation requires an authenticated attacker (PR:L) to inject a stored payload, and impact only materializes when a victim user interacts (UI:P), with impact confined to the subsequent system (SC:L/SI:L) and zero impact on the vulnerable system itself (VC:N/VI:N/VA:N). All exploitation signals reinforce low real-world risk: EPSS is 0.03% (9th percentile), there is no CISA KEV listing (no public exploit identified at time of analysis), and no POC is referenced - only the INCIBE-CERT advisory and the NVD detail page. No SSVC decision data was provided. The one thing to flag is that the input carries only a CVSS 4.0 vector and no 3.1 vector, and the 4.0 score maps the authenticated + user-interaction stored-XSS pattern conservatively; the description confirms the PR:L/UI:P gating (an authenticated attacker injects, then must lure another authenticated user), so no metric conflicts are apparent.

An authenticated low-privilege user of Ekushey CRM submits a project bug via /ekushey/index.php/client/project_bug/create/xxx with a malicious script payload in the 'title' or 'description' POST parameter, which is stored without sanitization. When another authenticated user (e.g., a staff member or admin) later views the bug record, the script executes in their browser and can exfiltrate their session cookie, enabling session hijacking. No public exploit code is identified at time of analysis.