IBM TRIRIGA CVE-2026-11372

Exploitation requires the attacker to hold a valid authenticated session on IBM TRIRIGA Application Platform (PR:L per CVSS vector) - anonymous access is insufficient. The application must be running version 5.0.2 or 5.0.3. At least one other user (ideally with higher privileges) must subsequently view the page or record into which the JavaScript payload was injected, triggering execution in their browser session. Limiting exploitation: the requirement for an active authenticated account prevents entirely unauthenticated attack; the credential-theft impact is realized only if a privileged victim browses the injected content. Organizations with strict role-based access control limiting which users can submit free-text input fields would reduce the attacker pool, though this is not a substitute for patching.

The NVD-assigned CVSS 3.1 score of 5.4 (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N) is noteworthy because UI:N is atypical for XSS - most stored XSS is rated UI:R since a victim must load the affected page. This metric choice may indicate the vendor believes the payload fires without requiring additional user navigation, or it may be a miscalibration. The C:L/I:L impact ratings are conservative; in practice, credential disclosure (as explicitly called out in the description) and session hijacking via stored XSS in an enterprise IWMS can result in lateral movement to higher-privileged accounts, elevating real-world impact beyond the base score. No EPSS data was provided, and this CVE is not listed in the CISA KEV catalog. No POC has been identified at time of analysis. Overall, this is a moderate-priority finding for organizations running TRIRIGA 5.0.2-5.0.3, elevated primarily by the credential-theft potential in multi-user enterprise deployments. The UI:N claim warrants independent verification against the vendor advisory.

An authenticated TRIRIGA user with minimal privileges - such as a facilities coordinator or read-write tenant account - navigates to a user-editable Web UI field (such as a work order description, asset note, or profile field) and submits a crafted payload containing malicious JavaScript. When a higher-privileged user such as a system administrator subsequently views the record containing the injected content, the script executes silently in their browser, exfiltrating their session token or credentials to an attacker-controlled endpoint. No public POC has been identified, but the technique is well-understood and requires no specialized tooling beyond a browser.