Energy CRM CVE-2025-40640

Requires an authenticated low-privileged account on Energy CRM v2025 (PR:L) able to reach the invoice-creation workflow and submit POST requests to /crm/create_invoice_submit.php. Exploitation is limited by the need for victim interaction (UI:P) - a second, typically higher-privileged user must view the stored payload in the invoice for the script to execute and session theft to occur. This is not an unauthenticated or default-configuration remote attack; it depends on having valid CRM credentials and on another user rendering the malicious invoice data.

This is a moderate, authentication-gated stored XSS with no evidence of real-world exploitation. The CVSS 4.0 vector (AV:N/AC:L/PR:L/UI:P) requires an authenticated low-privileged account to inject the payload and a victim to interact with the rendered content; impact is confined to the subsequent system (SC:L/SI:L) with no confidentiality/integrity/availability impact on the vulnerable system itself (VC:N/VI:N/VA:N), yielding a vendor score of 5.1 (medium). EPSS is low at 0.21% (10th percentile), there is no CISA KEV listing, and no public exploit is identified - all signals point to a low-priority, non-widespread issue rather than an active threat. The attack is practically limited because it needs an existing authenticated foothold plus victim interaction (likely a higher-privileged user viewing the crafted invoice), so exploitation is targeted and conditional rather than automatable or wormable. One minor tension: the description emphasizes cookie/session theft (a confidentiality-style outcome) while the 4.0 vector marks VC:N and places impact only on the subsequent system via SC:L/SI:L - consistent with XSS modeling but worth noting that session hijacking of a higher-privileged user is the realistic consequence.

An authenticated low-privileged user of Energy CRM submits a POST request to /crm/create_invoice_submit.php with a malicious script payload in the customerName_0 parameter, which is stored without validation. When another authenticated user (e.g., staff or an administrator) later views the invoice, the script executes in their browser and exfiltrates their session cookie. No public proof-of-concept exploit is identified at time of analysis.