CVE-2026-45296: OpenReplay Multi-Tenant Authorization Bypass – Session Data Exposure

Technical summary

The vulnerability resides in OpenReplay's Python API routes that handle app_apikey operations. When processing requests to retrieve or enumerate session data, the authorization logic validates the API key's authenticity and confirms the target projectKey exists in the system, but omits the crucial step of verifying that both the API key and projectKey belong to the same tenant. Because projectKey values are public and embedded in tracker JavaScript served to browsers, attackers can harvest project identifiers from victim organizations. An authenticated attacker with a valid API key for their own tenant can then craft requests targeting a different tenant's projectKey, bypassing the tenant boundary check. The affected routes allow session enumeration and retrieval of session event payloads containing user interaction data, form inputs, and other sensitive events. This is a classic incomplete authorization check (CWE-284) that conflates authentication with authorization in a multi-tenant context.

Business impact

A breach of tenant isolation in a session replay platform has severe implications. Session replay systems capture keystroke events, user interactions, and often form data—including passwords, PII, and business-sensitive information. An attacker exploiting this flaw can systematically extract all session events from a victim organization, enabling credential theft, data exfiltration, compliance violations, and reputational harm. For SaaS deployments of OpenReplay, this affects all customers sharing a cloud instance. Self-hosted deployments are at risk if multiple customers or departments are isolated via tenancy logic rather than separate infrastructure. The ease of exploitation—requiring only a valid API key and publicly available project identifiers—significantly lowers the barrier to abuse.

Affected systems

OpenReplay versions prior to 1.26.0 are vulnerable. The flaw affects all deployments (cloud and self-hosted) where multi-tenant isolation is relied upon and API keys are issued to multiple parties. Customers who have not yet deployed 1.26.0 or later should prioritize upgrades. The vulnerability does not require a specific configuration and will be present in all qualifying versions.

Exploitability

Exploitability is moderate to high. An attacker must possess a valid API key for any tenant—their own or compromised—but this is a common scenario in environments where multiple users, applications, or partners have API access. Once authenticated, discovering victim projectKey values is feasible because they are embedded in browser-side JavaScript, discoverable via HTTP traffic analysis, or potentially leaked in logs or documentation. The attack is entirely network-based, requires no user interaction, and can be automated for large-scale enumeration. However, the attacker must have legitimate API credentials; this is not an unauthenticated bypass.

Remediation

Upgrade OpenReplay to version 1.26.0 or later immediately. The patch implements proper tenant isolation by verifying that the API key and the requested projectKey both belong to the same tenant before processing authorization checks. Organizations unable to upgrade immediately should restrict API key distribution, monitor API logs for cross-tenant access patterns, and consider temporarily disabling unused API keys or high-privilege routes.

Patch guidance

Deploy OpenReplay 1.26.0 or later. Review the vendor release notes and testing in a non-production environment first to confirm compatibility with your deployment. Pay particular attention to any configuration changes related to API authorization or multi-tenant settings. Once patched, audit API key usage and revoke any unnecessary or compromised credentials.

Detection guidance

Monitor OpenReplay API logs for the following indicators: (1) requests to app_apikey routes from a single API key targeting projectKeys that belong to different tenants, (2) unusual patterns of session enumeration or data retrieval from unfamiliar project IDs, (3) authentication succeeding for projectKeys that should not be accessible to the calling API key. If log retention is available, search historical logs for similar patterns dating back to the vulnerability's public disclosure. Implement alerting on suspicious cross-tenant API activity.

Why prioritize this

This vulnerability merits immediate attention due to high CVSS (7.7), ease of exploitation for authenticated users, and severe impact on confidentiality and tenant isolation—a cornerstone of multi-tenant SaaS security. Session replay data is inherently sensitive and often contains credentials and PII. The attack requires only valid credentials and publicly discoverable project identifiers, making it a practical exploit. Any organization running a shared OpenReplay instance or offering OpenReplay to multiple tenants must patch urgently.

Risk score, explained

CVSS 7.7 (HIGH) reflects a network-accessible vulnerability requiring low privileges (L in PR) with no user interaction, affecting confidentiality significantly (C:H) but not integrity or availability. The scope is changed (S:C), meaning the security policy boundary of a resource beyond the vulnerable component (the tenant boundary) is impacted. This score appropriately captures a cross-tenant data exfiltration flaw in an authentication context.

Frequently asked questions