WebSphere Liberty CVE-2026-2482

The victim must have an active authenticated session with the IBM WebSphere Liberty application at the time of exploitation; without a valid session cookie, the forged request carries no privileged context and fails. The victim must also take an action that causes their browser to issue the cross-site request - visiting a malicious page, clicking a crafted link, or loading attacker-controlled content (CVSS UI:R confirmed). The attack does not require any privilege on the part of the attacker (CVSS PR:N). Exploitation is limited by the social engineering step required to reach authenticated users, the need to know or guess valid Liberty endpoint paths, and the fact that CSRF does not allow the attacker to read server responses - only to trigger server-side actions. Default browser SameSite cookie policies (Lax in modern browsers) may further constrain exploitability depending on request method and Liberty endpoint design.

The vendor-assigned CVSS base score of 8.8 (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H) reflects a high potential impact if exploitation succeeds, but several intelligence signals significantly temper real-world urgency. EPSS is 0.09% at the 0th percentile, indicating near-zero observed exploitation probability relative to the broader CVE population. SSVC classifies exploitation as none and technical impact as partial - the latter conflicts with the CVSS C:H/I:H/A:H triple-high assessment, suggesting the actual impact may depend on what specific operations the vulnerable Liberty endpoints expose. The UI:R requirement is a genuine constraint: exploitation requires a user with an active authenticated session to be socially engineered into visiting attacker-controlled content. SSVC also flags automatable: no, aligning with the UI:R dependency. Taken together, this is a meaningful vulnerability for organizations running affected Liberty deployments, but not a fire-drill priority absent evidence of targeting.

An attacker crafts a malicious web page containing a hidden HTML form or JavaScript fetch that targets a sensitive Liberty application endpoint (such as account modification or data deletion). When an employee with an active Liberty session visits the attacker's page - via a phishing email or compromised website - the victim's browser automatically includes their session cookie in the forged request, causing the server to execute the action as the authenticated user. No public proof-of-concept code has been identified at time of analysis.