IBM TRIRIGA CVE-2026-93892

Requires a valid authenticated session on IBM TRIRIGA Application Platform (version 5.0.0 through 5.0.8); the CVSS PR:L confirms authentication is needed. The specific condition is that session tokens are rendered into the HTML response body, so an authenticated attacker who can view those responses can extract tokens. Limiting factors: exploitation is bounded to authenticated users (not anonymous internet attackers), and real impact depends on whether the exposed tokens belong to other, higher-privileged users rather than only the attacker's own session - if only the attacker's own token is exposed, impact is minimal. No special non-default configuration is indicated in the available data.

This is a credible but not top-tier priority. The vendor CVSS of 8.1 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N) reflects a network-reachable, low-complexity flaw requiring only low-privilege authentication (PR:L) and no user interaction. The core weakness (CWE-200) is exposure of session tokens in the HTML response, which realistically enables session hijacking/account takeover of other users. No EPSS score, KEV listing, or POC was supplied in the input, so exploitation likelihood cannot be quantified: there is no public exploit identified at time of analysis and no evidence of active exploitation. The main tension is the vendor's I:H rating: a pure information-disclosure bug (CWE-200) directly impacts confidentiality, while the integrity impact is a downstream consequence of reusing stolen tokens - I assess the direct impact as primarily confidentiality (see assessed vector) and flag the I:H as likely crediting the session-hijack follow-on. Because exploitation requires an authenticated session, risk is bounded to environments where attackers can obtain even low-privilege TRIRIGA credentials. Net: patch promptly given it is network-exploitable with low privileges, but treat it as elevated-not-emergency absent any exploitation signal.

A low-privileged but authenticated TRIRIGA user (or an attacker who has phished/obtained basic credentials) requests an application page and observes another user's session token embedded in the returned HTML. The attacker replays that token to impersonate the victim and access their data or functions. No public exploit code is identified at time of analysis; exploitation requires valid authentication and the ability to observe HTML responses containing the leaked tokens.