Liferay Portal CVE-2025-62252

Exploitation requires an authenticated account (PR:L) within a Liferay virtual instance and access to the Users Admin portlet (UsersAdminPortlet) organization-assignment function; the attacker tampers with the _com_liferay_users_admin_web_portlet_UsersAdminPortlet_addUserIds parameter to reference a user ID belonging to a different virtual instance. The exploitation is limited by the requirement for valid authentication and by its scope: impact is restricted to assigning organizations to users (an integrity-only effect, VI:L) with no data disclosure or service disruption. The bug is most meaningful in multi-tenant deployments that rely on virtual-instance isolation as a security boundary; single-instance deployments see minimal practical impact.

This is a genuinely moderate-to-low priority issue rather than a high-severity emergency, and the signals are largely consistent in pointing that way. The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) scores 5.3 and shows only a single low-integrity impact (VI:L) with no confidentiality or availability impact and no stated subsequent-system impact - consistent with CWE-639 (IDOR / authorization bypass through a user-controlled key). Exploitation requires an already-authenticated user (PR:L), so this is not an unauthenticated internet-facing bug. The EPSS score of 0.27% (18th percentile) is low and reinforces that mass exploitation is not expected; there is no CISA KEV listing and no public exploit identified at time of analysis, so there is no evidence of active exploitation or weaponization. One point worth flagging: the real-world impact is a multi-tenancy / virtual-instance isolation breach (an authenticated user in one virtual instance can act on a user in a different virtual instance), which the vendor's vector scores as no scope/subsequent-system impact (SC/SI/SA:N) - I assess the cross-tenant boundary crossing as arguably a scope change, which somewhat understates the architectural significance for multi-tenant Liferay deployments even though the raw technical impact remains low-integrity-only. No conflicting signals between attack vector and description were found; the primary caveat is that all data traces to a single Liferay advisory with no independent corroboration.

An attacker holds a legitimate low-privilege authenticated account in one Liferay virtual instance (tenant). By manipulating the _com_liferay_users_admin_web_portlet_UsersAdminPortlet_addUserIds parameter in a request to the Users Admin portlet, they reference and assign an organization to a user account belonging to a completely different virtual instance, breaching tenant isolation. No public exploit code is identified, but the low attack complexity (AC:L) and network vector make crafting the manipulated request straightforward for an authenticated user.