Telerik Report Server CVE-2026-106155

Exploitation requires an authenticated account with report-authoring privileges on the Telerik Report Server (PR:L), used to embed a javascript: or vbscript: URL inside a report's navigation action or an HTML text-box link. A separate, higher-privilege user (e.g., an administrator) must then open the malicious report in the web report viewer AND trigger the embedded navigation (UI:R) for the payload to fire in their session. Privilege escalation specifically depends on a multi-user Report Server deployment where a higher-privilege user views attacker-authored content. Limiting factors: attacker must already be an authenticated report author, victim interaction with the crafted report is mandatory, and impact is confined to versions prior to 12.2.26.1007.

This is a genuine, well-above-average priority in environments that actually run Telerik Report Server, but it is not a drop-everything internet-wide emergency. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:L, score 8.9) is internally consistent with the description: network-reachable web viewer, low attack complexity, but it explicitly requires an already-authenticated low-privilege report author (PR:L) and a victim to view the report and trigger the embedded navigation (UI:R). The scope change (S:C) and high confidentiality/integrity impact come from script executing in a higher-privilege user's origin - classic stored-XSS privilege escalation. Key signals are MISSING rather than conflicting: there is no EPSS score, no CISA KEV listing, and no public POC referenced in the input, so exploitation status is 'no public exploit identified at time of analysis.' No SSVC decision data was provided. The two non-trivial gating factors - attacker must hold a valid report-author account AND a higher-privilege user must open the booby-trapped report - make this better suited to insider/post-foothold privilege escalation than to mass, unauthenticated opportunistic attacks. Treat as high priority for multi-user Report Server deployments (patch promptly), but the real-world likelihood of spray-and-pray exploitation is tempered by the authentication and user-interaction requirements.

A low-privileged but authenticated report author creates or edits a report and embeds a javascript: or vbscript: URL in a navigation action or HTML text-box link. They then get an administrator or other higher-privilege user to open and interact with that report in the web report viewer, causing the attacker's script to run in the admin's authenticated session and perform privileged actions on their behalf. No public exploit code is identified at time of analysis, though the technique is straightforward for anyone with report-authoring access.