Liferay Portal CVE-2025-62259

Exploitation requires the target Liferay instance to expose API endpoints (headless/REST/JSON web services) and to allow a user to reach an authenticated-but-unverified state - i.e., the account exists but email verification has not completed. The limiting factor is that the attacker must be able to obtain such a session, which in practice means the portal permits open/self-service user registration; instances that disable self-registration or admin-provision all accounts sharply reduce exposure. No user interaction from a victim is required (UI:N), and impact is bounded to low-level read and edit of content (VC:L/VI:L), with no availability impact. The vendor marks it PR:N, but the described 'before email verification' gating implies possession of a registered account.

This is a medium-severity authorization flaw (CVSS 4.0 base 6.9, CWE-863) with a vendor-supplied vector of AV:N/AC:L/PR:N/UI:N and low confidentiality/integrity impact (VC:L/VI:L), no availability impact. All signals point to a real-but-not-urgent issue rather than an emergency: EPSS is low at 0.22% (12th percentile), there is no CISA KEV listing, and no public exploit code was identified. The signals are internally consistent - a low EPSS and absence of KEV/POC align with the modest CVSS impact ratings. One point of tension: the vendor scores this PR:N (unauthenticated), yet the description states the flaw concerns access 'before a user has verified their email address,' which implies the attacker has already registered an account and holds a session - i.e., some form of pre-verification authentication, closer to PR:L. Verify the exact pre-conditions (open self-registration vs. admin-provisioned accounts) with Liferay, as this materially changes exploitability. Overall: a legitimate access-control defect warranting patching on a normal cycle, not a drop-everything priority.

An attacker self-registers an account on a Liferay Portal or DXP instance that permits open registration but does not yet confirm the email address, then invokes the headless/REST API endpoints that should have been gated behind email verification. Using that unverified session, they read and modify content they should not yet be able to touch. No public proof-of-concept exploit has been identified at the time of analysis.