What is the CVSS score of CVE-2026-45296?

CVE-2026-45296 has a CVSS 3.1 base score of 7.7 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N. EPSS exploitation probability: 0.0%.

Which versions of OpenReplay are affected by CVE-2026-45296?

OpenReplay self-hosted session replay platform (versions prior to 1.26.0) allows any user holding a valid API key to retrieve session recordings and event data from other customer tenants due to…. A patch is available.

How to fix or mitigate CVE-2026-45296?

24 hours: Identify all OpenReplay deployments, document current versions, and assess the sensitivity of captured session data. 7 days: Restrict API endpoint access using network firewalls or Web Application Firewall (WAF) rules; enable comprehensive API request logging with real-time alerts for cross-tenant access attempts. 30 days: Upgrade all instances to OpenReplay version 1.26.0 or later; conduct forensic analysis of API logs for evidence of exploitation.

OpenReplay CVE-2026-45296

EUVD-2026-32971 HIGH

Improper Access Control (CWE-284)

2026-05-28 GitHub_M

Python Authentication Bypass

7.7

CVSS 3.1 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

7.7 HIGH

AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N

Primary rating from GitHub Advisory · only source for this CVE.

CVSS VectorGitHub Advisory

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Changed

Confidentiality

High

Integrity

None

Availability

None

Lifecycle Timeline

Patch available

May 28, 2026 - 19:02 EUVD

Analysis Generated

May 28, 2026 - 18:15 vuln.today

DescriptionGitHub Advisory

OpenReplay is a self-hosted session replay suite. Prior to 1.26.0, OpenReplay's Python API exposes several app_apikey routes that trust a caller-provided projectKey after validating only that the API key itself is valid and that the target projectKey exists. The authorization flow does not verify that the authenticated API key and the requested project belong to the same tenant. Because the public tracker design exposes projectKey to browser-side code, an attacker who owns any valid API key for their own tenant can target another tenant's project by reusing that public projectKey. The vulnerable routes allow the attacker to enumerate victim user sessions and then retrieve sensitive session event data across the tenant boundary. This vulnerability is fixed in 1.26.0.

AnalysisAI

Cross-tenant data exposure in OpenReplay self-hosted session replay suite (versions prior to 1.26.0) allows an attacker holding any valid API key for their own tenant to enumerate sessions and retrieve sensitive session event data belonging to other tenants. The flaw stems from app_apikey routes in the Python API that validate the API key and the existence of a projectKey independently, but never confirm the two belong to the same tenant. No public exploit identified at time of analysis, though the trivial nature of the abuse (substituting a browser-visible projectKey) makes weaponization straightforward.

Technical ContextAI

OpenReplay is an open-source, self-hosted session replay platform whose Python API services serve as the authorization layer for replay and analytics endpoints. The CPE cpe:2.3:a:openreplay:openreplay covers all versions prior to 1.26.0. The root cause maps to CWE-284 (Improper Access Control): the app_apikey-prefixed routes accept a caller-supplied projectKey, validate that the API key is well-formed and that the projectKey exists in the database, but never enforce that the two share a tenant/organization scope. Because projectKey is intentionally embedded in the public JavaScript tracker shipped to end-user browsers, it is treated as a public identifier - yet the API treats possession of a valid API key plus knowledge of a projectKey as sufficient authorization, collapsing the multi-tenant boundary.

RemediationAI

Vendor-released patch: upgrade to OpenReplay 1.26.0 or later, which adds tenant-scope verification between the authenticated API key and the requested projectKey; details are in the advisory at https://github.com/openreplay/openreplay/security/advisories/GHSA-8wmc-vpmf-cjf5. If an immediate upgrade is not possible, operators of multi-tenant deployments should restrict network access to the Python API so that only trusted tenants or internal services can reach the app_apikey routes (trade-off: breaks legitimate third-party API integrations), rotate API keys and treat any cross-tenant projectKey access in logs as suspicious, and consider running each tenant in an isolated deployment until patched (trade-off: operational overhead). Single-tenant deployments face limited exposure but should still patch.