Liferay DXP CVE-2025-62242

Requires a valid authenticated Liferay account (CVSS PR:L) with access to the Account Entries Admin portlet (_com_liferay_account_admin_web_internal_portlet_AccountEntriesAdminPortlet); the attacker then supplies another account's identifier in the addressId parameter. No user interaction is needed (UI:N). Limiting factors: exploitation is gated behind authentication, so risk rises sharply where self-registration is enabled or many tenants/accounts share the instance, and falls where accounts are tightly controlled. Impact is limited to reading address data of other accounts (confidentiality only); no data modification or service disruption is possible. Affected deployments are Liferay Portal 7.4.3.4-7.4.3.111 and Liferay DXP 2023.Q4.0-2023.Q4.5, 2023.Q3.1-2023.Q3.8, and 7.4 GA through update 92.

This is a genuine but low-to-medium priority issue, not a top-tier emergency. The CVSS 4.0 vector (AV:N/AC:L/PR:L/UI:N) and the CWE-639 IDOR classification agree with the description: a remote, already-authenticated user with a low-privilege account can read address data belonging to a different account by tampering with the addressId parameter. All signals point the same direction and are internally consistent - impact is confined to confidentiality (VC:L, with VI:N/VA:N), matching the 5.3 Medium base score. EPSS is low at 0.30% (21st percentile), there is no CISA KEV listing, and no public proof-of-concept is referenced, so exploitation status is 'no public exploit identified at time of analysis.' The principal caveat is that exploitation requires a valid authenticated account (PR:L), which substantially limits the attacker population to insiders or anyone able to self-register where registration is open. Nothing in the data conflicts, but note the sole reference URL points to advisory content for CVE-2025-62245 rather than this CVE (-62242), so the linked advisory should be verified against the correct identifier. Net: prioritize patching on multi-tenant or self-registration Liferay deployments where account address data is sensitive, but this does not warrant out-of-band emergency response.

A low-privilege authenticated user (or anyone who can self-register on an open Liferay portal) logs in and issues a request to the Account Entries Admin portlet, substituting a different account's identifier in the _com_liferay_account_admin_web_internal_portlet_AccountEntriesAdminPortlet_addressId parameter. Because the application fails to verify that the referenced address belongs to the requester's account, it returns another account's address details. No public exploit code is identified; the attack requires only a crafted authenticated HTTP request with no special tooling or user interaction.