Open Source POS CVE-2025-66923

Exploitation requires an authenticated back-office account with privileges to create or update customer records (the input CVSS PR:H confirms high privileges are needed), and the injected payload in the phone_number field only fires when a second user opens the affected customer record - so realistic abuse depends on a victim viewing the record. This limits the attack to malicious insiders or attackers who have already obtained privileged POS credentials; it is not remotely exploitable against an unauthenticated internet-facing surface. Affected configuration is Open Source Point of Sale v3.4.1 specifically.

This is a moderate-risk, not a high-priority, issue despite the 7.2 CVSS score. The input CVSS vector (AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H) is internally inconsistent with the vulnerability class: a stored/reflected XSS in a customer-record field (CWE-20, 'XSS') does not plausibly yield High confidentiality, integrity AND availability impact on an unchanged scope, and it realistically requires victim interaction (UI:R), not UI:N - this appears to be an inflated/mislabeled vector and should be verified rather than trusted. Supporting signals point to low real-world urgency: EPSS is only 0.55% (45th percentile), there is NO CISA KEV listing, and exploitation is gated behind PR:H (a privileged, authenticated back-office user who can create/update customers). A public exploit write-up does exist (GitHub PoC), so proof-of-concept is confirmed, but publicly available exploit code is a distinct signal from active exploitation and none is reported here. Net: the attacker must already be an authenticated privileged POS operator to inject the payload, which substantially narrows the threat to insider or post-compromise scenarios. Treat as a routine patch item, not an emergency.

An authenticated privileged POS user (or an attacker who has stolen such credentials) edits a customer and places a malicious script in the phone_number field, which is stored without sanitization. When another staff member or admin later opens that customer record in the back office, the script executes in their browser session, enabling session/cookie theft or actions in their authentication context. A public proof-of-concept for this exact parameter is available on GitHub.