Liferay DXP CVE-2025-43822

Exploitation requires an authenticated account with privileges to create or edit a Terms and Conditions entry's Name text field for either a Payment Term or a Delivery Term within Liferay's Commerce/order functionality (hence PR:L, not PR:N). The payload only fires when a second user - typically a back-office operator or customer viewing the order - loads the view order page that renders the stored term (UI:A/user interaction required). Limiting factors: the attacker cannot act fully unauthenticated, the malicious term must be reachable and rendered to a victim, and impact is confined to script execution in the victim's browser context (no direct server compromise, VA:N). This narrows realistic abuse to environments running Liferay Commerce with multi-user order workflows.

This is a genuinely low-to-moderate priority issue, and the multiple signals are consistent rather than conflicting. The CVSS 4.0 base score is 4.8 (Medium) with AV:N/AC:L/AT:N/PR:L/UI:A - network reachable but requiring both low-level authentication (PR:L) and victim interaction (UI:A), with only Low confidentiality and integrity impact and no availability impact (VC:L/VI:L/VA:N). This profile matches a typical stored XSS (CWE-79). The exploitation-probability signals reinforce low urgency: EPSS is 0.22% (12th percentile), the CVE is NOT on the CISA KEV list, and no public exploit code is referenced. There is no SSVC decision data in the input to incorporate. All signals align - low EPSS, no active exploitation, no POC, authenticated-and-interactive attack requirement - so this is a high-CVSS-but-not-really issue only in the sense that even its CVSS is modest. It is a legitimate finding to patch during normal maintenance, not an emergency. No signals conflict; the main caveat is that POC/exploitation status is simply absent from the provided intelligence rather than confirmed negative.

An authenticated low-privileged user of a Liferay Commerce store injects a malicious script payload into the Name text field of a Payment Term or Delivery Term in a Terms and Conditions entry. When a back-office operator or another user later opens the view order page that renders that term, the stored script executes in their browser session. No public exploit code is identified at time of analysis, but stored XSS of this type is straightforward to craft.