FeelCRM-OS EUVD-2026-92393

Exploitation requires an authenticated low-privileged account with access to the Create Customer endpoint (PR:L) and the ability to submit the customer_form[remark] field, whose value is passed through htmlspecialchars_decode in CrmDefineFormModel.class.php and stored without re-sanitization. Triggering the payload additionally requires a second user (e.g., an operator or administrator) to view the affected customer record (UI:P / passive interaction), so this is a stored/second-order XSS that cannot fire without a victim rendering the record. Limiting factors: valid credentials are needed, victim interaction is required, the product is niche with no known default internet-facing deployment, and no vendor patch exists. There is no indication the flaw is reachable fully unauthenticated.

This is a low-to-moderate priority issue despite the 'medium' CVSS 4.0 score of 5.1. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:P/VC:N/VI:L/VA:N) indicates a network-reachable but privilege- and interaction-gated cross-site scripting flaw: an attacker needs an existing low-privileged account (PR:L) and a victim must passively interact (UI:P) for the injected payload in the customer remark field to fire. Technical impact is limited to low integrity (VI:L) with no confidentiality or availability impact claimed in the input vector. Exploitation signals are mixed and mostly weak: publicly available exploit code exists (referenced via the GitHub issue, E:P in the vector confirms a proof-of-concept maturity), but this CVE is NOT listed in CISA KEV and no EPSS probability was provided in the input, so there is no evidence of widespread or active real-world exploitation. The SSVC exploitation status corresponds to 'proof-of-concept' rather than 'active.' Netting these out: a POC exists for a privilege-gated stored XSS in an obscure product, which argues for targeted/opportunistic risk at most rather than mass exploitation. Note one conflict to verify: the input VC:N/VI:L understates typical stored-XSS impact (session/cookie theft usually implies at least low confidentiality impact), so the real impact may be modestly higher than the supplied vector suggests.

A low-privileged authenticated user with access to the Create Customer endpoint submits a crafted script payload in the customer_form[remark] field, which is improperly handled by htmlspecialchars_decode and stored. When another user or administrator later views that customer record, the stored JavaScript executes in their browser session. A public proof-of-concept exists (filed as a GitHub issue), lowering the effort required to reproduce the attack.