External risk intelligence

OpenReplay SDK Cross-Site Scripting Account Takeover

CVE advisorySeverity: CRITICAL (CVSS 9.3)

CVE-2026-55879

OpenReplay is a self-hosted session replay suite designed to be embedded in public-facing web applications. The tracking SDK is inherently exposed to the internet to collect visitor data, making it a common deployment pattern for the product to interact with untrusted public traffic.

Cross-site Scripting

Halo Surface Signal: 4 out of 5 — likely to be public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

This vulnerability affects OpenReplay, a self-hosted session replay tool. An unauthenticated attacker could potentially compromise user accounts by injecting malicious scripts through custom event data. The main concern is confirming relevance and exposure within your organization.

Script injection allows account takeover.
Affects self-hosted session replay tools.
Confirm if OpenReplay is in use.

Attack Path

How an attacker could exploit the issue

An unauthenticated attacker can target users of the OpenReplay dashboard by sending specially crafted event data. The vulnerable component is the tracking SDK, which accepts custom event names and URLs from any visitor. This data is stored and later rendered without proper encoding in the dashboard. When a user views this data, an embedded script can execute within the dashboard's origin, allowing the attacker to steal the session's JWT from local storage and potentially take over the account.

Unauthenticated user can send data.
Vulnerable SDK renders script in dashboard.
Account takeover risk.

Live Threat

Current exploitation, exposure, and threat context

An unauthenticated attacker could inject scripts into the OpenReplay dashboard, allowing them to steal session JWTs and take over authenticated user accounts. This occurs when custom event names and captured page URLs are processed without proper output encoding.

Authenticated dashboard accounts.
Script injection via custom event data.
Account takeover by attackers.

Operational Fix

Recommended remediation, mitigation, and detection steps

Real-world ownership of this critical vulnerability likely falls to the platform or infrastructure teams managing the self-hosted OpenReplay instance, with coordination from application owners. The first practical step is to identify all deployments of OpenReplay, confirm their reachability and business criticality, and then identify the accountable owner for each instance to plan targeted remediation.

Platform or infrastructure teams own remediation.
Verify OpenReplay deployment reachability and criticality.
Coordinate updates with application owners.

Supplementary metadata

CVSS vector

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Free EASM Trial See How Signal Works

Frequently asked questions

What is OpenReplay?

OpenReplay is a self-hosted software suite used by developers to record and replay user sessions on their websites. By integrating a tracking SDK into their web pages, administrators can observe how visitors interact with the site, helping them diagnose bugs and improve the user experience. Because it records actual visitor behavior, it acts as a bridge between public-facing web traffic and the internal administrative dashboard where session data is analyzed.

What does CVE-2026-55879 mean?

This CVE describes a Cross-Site Scripting (CWE-79) vulnerability. In simple terms, the software fails to clean or 'encode' the data it receives from website visitors before displaying it in the admin dashboard. Because this input is treated as trusted code rather than plain text, a malicious actor can hide a script within a fake event name or URL. When an administrator views that event, the script runs automatically, which can lead to unauthorized access to the dashboard.

How does an attacker trigger this vulnerability?

The attack is triggered when someone submits crafted data—specifically custom event names or page URLs—through the OpenReplay tracking SDK. Because the SDK is designed to accept data from any visitor, an attacker does not need an existing account or password to send this malicious input. Importantly, simply having OpenReplay installed is not enough; the malicious script only executes when an administrator actually opens the dashboard and views the specific, compromised session data.

Do I need to worry about this if my OpenReplay instance is internal?

Yes, you should still evaluate the risk. According to Halo Surface Signal, OpenReplay is designed to be embedded in public-facing applications, meaning the tracking SDK is inherently exposed to untrusted traffic regardless of where the dashboard itself resides. Even if your dashboard is only accessible on an internal network, the component that accepts the malicious input is intentionally placed on the internet to gather data, providing a path for the attack to reach your environment.

What should I do first to address this CVE?

Your first step is to locate all instances of OpenReplay running within your infrastructure to determine which versions are active. Once you have identified these deployments, coordinate with the teams responsible for those systems to upgrade to version 1.25.0 or later. This version contains the necessary security updates to ensure that incoming visitor data is properly encoded before it is rendered, which neutralizes the script injection risk.

References

Written by Nicholas Merritt

Nicholas Merritt is VP of Security Solutions at Halo Security. With more than 25 years across application security, vulnerability prioritization, and offensive security, he helps teams translate threat data into practical exposure validation and remediation focus. He authors Halo Threat Intelligence CVE advisories using Halo Surface Signal and H/A/L/O context to prioritize internet-facing risk.