Liferay Portal CVE-2025-62246

Requires an authenticated Liferay account (PR:L) with the ordinary ability to edit one's own first/middle/last name fields - a default capability for standard users. The malicious name must then be rendered through a mention or comment feature (page comments widget, blog entry comments, document and media comments, message board messages, wiki page comments, or other mention-supporting apps), and a second user must actively view that content for the stored payload to fire (UI:A). Limiting factors: exploitation is gated by authentication and by requiring victim interaction, and impact is amplified only if the viewing user holds elevated privileges; no non-default configuration is needed since mentions and comments are standard portal features.

This is a low-to-moderate priority issue rather than an urgent one, and the available signals are consistent rather than conflicting. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:A/VC:L/VI:L/VA:L) describes a network-reachable but authenticated (PR:L) stored XSS that requires victim interaction (UI:A) and yields only LOW impact across confidentiality, integrity, and availability with no subsequent-system impact - hence the modest 4.8 base score. EPSS reinforces this: a 0.22% exploitation probability at the 12th percentile indicates very low likelihood of near-term mass exploitation. There is no CISA KEV listing and no public exploit identified at time of analysis, so there is no evidence of active exploitation. The one caveat is that stored XSS can be chained (e.g., to hijack an admin session if a privileged user views the payload), which can elevate real-world impact beyond the LOW base metrics, but nothing in the provided data confirms such chaining. Net: a genuine defect worth patching in routine cycles, not an emergency.

A low-privileged but authenticated Liferay user edits their own profile and places a malicious script in their first, middle, or last name field, then @-mentions or comments where that name is rendered (page comments, blog/document comments, message boards, or wiki pages). When another user - potentially an administrator - views the comment or mention, the stored script executes in their browser session. No public exploit code was identified at time of analysis, and because UI:A applies, exploitation depends on a victim actually viewing the attacker-controlled content.