Liferay Portal CVE-2025-62261

Exploitation requires the attacker to already have read access to the Liferay Portal/DXP backend database where password reset tokens are stored in cleartext (CWE-312) - this is reflected by PR:H in the CVSS vector. There is no remote unauthenticated path: the attacker must first compromise the database through a separate vector (e.g., SQL injection, exposed database backup, misconfigured/unsecured DB, or insider access). The limiting factors are therefore substantial: the plaintext storage is only dangerous once database confidentiality is already breached, and exploitation targets individual accounts via the standard reset flow rather than enabling mass or automated takeover against default internet-facing configurations.

This is a medium-severity, low-priority issue in practice. The vulnerability (CWE-312, cleartext storage of password reset tokens) carries a CVSS 4.0 base score of 6.9. Although the official CVSS vector is AV:N, the real-world prerequisite is PR:H - the attacker must already possess read access to the Liferay backend database, which is the gating control. This creates a notable tension: the AV:N label suggests network reach, but exploitation genuinely depends on prior database compromise, so the network-vector framing overstates remote reachability - the database-access precondition is the true barrier. The exploitation-probability signals all point low: EPSS is 0.29% (20th percentile), the CVE is NOT in CISA KEV, and no public proof-of-concept is referenced. Technical impact is scoped to confidentiality (VC:H) with no integrity or availability impact in the vendor vector, though the downstream account-takeover arguably extends to integrity. Taken together, the signals are consistent rather than conflicting - moderate severity, low exploitation likelihood, and a strong access precondition - making this a defense-in-depth/hardening fix rather than an emergency patch. It becomes materially dangerous only when combined with a separate flaw that yields database access (SQLi, exposed backup, insider, or misconfigured DB).

An attacker who has already obtained read access to the Liferay database - for example via SQL injection, an exposed or stolen database backup, or insider access - queries the table storing password reset tokens and retrieves one in plaintext. The attacker then submits that valid token through the normal password-reset flow to set a new password and take over the targeted user's account. No public exploit code is referenced, and the attack requires the pre-existing database foothold rather than any remote unauthenticated trigger.