PILOS CVE-2025-62781

Exploitation requires the attacker to ALREADY possess a valid session token for a PILOS local account (not an SSO/external account) - obtained through a separate, unspecified vulnerability - because this flaw itself only concerns the failure to invalidate that existing token. The triggering event is the legitimate user performing a password change on a local account while logged in: PILOS terminates all other sessions but does not refresh or revoke the currently active session's token. Limiting factors: it affects only local-account users, provides no new access on its own (PR:L assumes held credentials/token), and is remediated entirely by upgrading to 4.8.0. It does not enable initial compromise and has no effect absent a prior token theft.

This is a medium-severity (CVSS 5.0) session management weakness (CWE-613, Insufficient Session Expiration) that is explicitly a CHAINED vulnerability - the provided CVSS vector (AV:N/AC:H/PR:L/UI:N) and the description agree that exploitation presupposes the attacker has ALREADY obtained a valid session token 'through another vulnerability.' This dependency is the dominant risk factor: in isolation CVE-2025-62781 cannot be exploited, which is consistent with the low EPSS score (0.17%, 6th percentile) indicating negligible probability of mass exploitation. There is no CISA KEV listing and no POC referenced in the input, so exploitation status is 'no public exploit identified at time of analysis.' The signals are coherent rather than conflicting: low EPSS, no KEV, no POC, AC:H, and PR:L all point to a low-urgency, defense-in-depth fix rather than an emergency patch. The one caveat worth stating explicitly is that the CVSS impact (C:L/I:L/A:L) scores the standalone flaw; the real-world severity rises sharply if a token-theft vulnerability also exists, since this flaw defeats password rotation as a remediation for that prior compromise. Treat as a priority to patch for environments that have had any session-token exposure, but not a standalone high-risk issue.

An attacker who has previously stolen a user's PILOS session token (via XSS, token leakage, or another flaw) retains access even after the victim notices suspicious activity and changes their password. Because the current session's token is not refreshed or invalidated on password change, the victim's natural remediation step fails and the attacker continues acting as the user. No public exploit code is identified; exploitation requires the attacker to first hold a valid stolen token (AC:H reflects this prerequisite).