Critical OpenReplay XSS Bug (CVE-2026-55879) Enables Full Dashboard Account Takeover

A critical vulnerability in OpenReplay, the popular open-source session replay and product analytics platform, allows completely unauthenticated attackers to seize control of privileged dashboard accounts through a stored cross-site scripting (XSS) chain.

Tracked as CVE-2026-55879 and assigned a Critical severity rating, the flaw exposes any organization running affected OpenReplay deployments to full session hijacking, project takeover, and unauthorized access to sensitive analytics data.

The vulnerability was disclosed via GitHub Security Advisory GHSA-3mfc-7hf4-jfxh, published last month by researcher estradino, with credit for discovery going to Jan Kahmen of German security firm turingpoint.

Critical OpenReplay XSS Bug

OpenReplay’s tracking SDK is designed to be embedded on any monitored website, using a public project key that is shipped inline with the tracker snippet. That key was never meant to be secret, but this design decision becomes the root of the problem.

Attackers can call tracker.event(name, payload) to send custom event names and captured page URLs directly into OpenReplay’s ClickHouse backend, with zero authentication required.

Because these values are stored without proper output encoding, they are later rendered in the authenticated dashboard viewed by legitimate, logged-in team members.

The technical failure compounds inside OpenReplay’s TextEllipsis component, which measures text width by assigning raw event values to innerHTML and appending them to the document body.

Malicious markup embedded in an event name becomes live, executable DOM content running in the dashboard’s own origin. The event-details modal renders this poisoned value twice: once in its default “pretty” view, and again through dangerouslySetInnerHTML in the JSON view, doubling the attack surface.

The final piece of the exploit chain involves the dashboard’s session management. OpenReplay does not serve a Content-Security-Policy header, leaving no browser-level defense against injected scripts. Worse, the session JWT is stored in localStorage under UserStore.jwt, fully readable by any JavaScript running on the page.

Once a script executes in the dashboard origin, it can silently extract this token and exfiltrate it to an attacker-controlled server. With the stolen JWT, the attacker impersonates the victim outright, accessing sessions, dashboards, project settings, and member controls exactly as the legitimate user would.

The CVSS 3.1 vector AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N reflects an attack requiring no privileges and minimal complexity, only needing a victim to view a malicious event during normal workflow.

The vulnerability impacts OpenReplay versions 1.24.0 and above. A patch is available starting with version 1.25.0. Organizations running self-hosted OpenReplay instances should:

Upgrade immediately to version 1.25.0 or newer
Audit dashboard access logs for anomalous event names containing script-like payloads
Rotate all active session tokens following the update
Implement a strict Content-Security-Policy as defense-in-depth
Avoid storing sensitive tokens in localStorage in custom deployments, favoring HttpOnly cookies instead

This case underscores a recurring theme in session-replay and analytics tooling: features built for convenience, such as public project keys and flexible custom event ingestion, can quietly become attacker footholds when output encoding and token storage aren’t treated as first-class security concerns.