PublicCMS CVE-2026-120319

Requires an authenticated low-privilege account on the target PublicCMS instance (PR:L) and that the publiccms-trade component with its refund functionality is deployed and in use - this is an optional e-commerce/trade module, not core CMS content serving, so instances without trade/refund workflows are not exposed. Exploitation itself needs no user interaction (UI:N) and no special timing or configuration beyond reaching the refund update endpoint and supplying a refundId belonging to another account. The limiting factors are therefore the authentication requirement and the need for the trade module to be active; there is no fixed version listed in the available evidence and the vendor did not respond, so no vendor mitigation is stated.

This is a medium-severity issue whose signals are internally consistent and point to moderate, not urgent, real-world risk. The CVSS 4.0 base score is 5.3 with vector AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L: network-reachable and low-complexity, but requiring low-privilege authentication (PR:L) and yielding only LOW confidentiality, integrity and availability impact to the vulnerable system with no scope/subsequent-system effect. This matches CWE-639 (Authorization Bypass Through User-Controlled Key / IDOR): an authenticated user manipulates the refundId key to reach refund records they should not control, rather than achieving full compromise. Exploit maturity is E:P (proof-of-concept), and the vuln.today decision label is 'this_month' - not act_now or emergency - so the decision framework itself treats this as a schedulable fix, not a drop-everything event. There is NO CISA KEV listing and NO EPSS score in the provided data, so widespread or confirmed active exploitation cannot be asserted; absence of those feeds is a data gap, not evidence of safety. The one meaningful amplifier is that the vendor (Sanluan) was contacted but did not respond, meaning no coordinated fix is signalled and a public disclosure exists with no vendor patch to pair against it. Net: a genuine but bounded authorization-bypass bug - prioritize within a normal monthly patch cycle for PublicCMS trade deployments, not as an emergency.

An attacker who holds any valid low-privilege account on a PublicCMS instance with the trade/refund component in use sends a crafted request to the refund update flow and substitutes another user's refundId value. Because the server does not verify that the refundId belongs to the caller, the request bypasses authorization and lets the attacker read or alter refund records that are not theirs. A public proof-of-concept is referenced via VulDB, and the low attack complexity (AC:L) means no special timing or environmental conditions are needed once authenticated.