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

OpenReplay self-hosted session replay backend versions 1.22.0 through 1.26.x contain a cross-tenant information disclosure vulnerability allowing any authenticated user to access other customers'…. A patch is available.

How to fix or mitigate CVE-2026-55881?

Within 24 hours: Identify all deployed OpenReplay instances and confirm versions. Within 7 days: Upgrade to version 1.27.0 or later. Within 30 days: Complete the upgrade across all environments and conduct access log review to identify potential unauthorized cross-tenant data access.

OpenReplay CVE-2026-55881

Q: What is the CVSS score of CVE-2026-55881?

CVE-2026-55881 has a CVSS 4.0 base score of 7.1 (High). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.2%.

EUVD-2026-43033 HIGH

Authorization Bypass Through User-Controlled Key (CWE-639)

2026-07-10 GitHub_M

Authentication Bypass Openreplay

7.1

CVSS 4.0 · Vendor: GitHub_M

Severity by source

Vendor (GitHub_M) PRIMARY

7.1 HIGH

CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

vuln.today AI

4.3 MEDIUM

Network-reachable IDOR needing only a low-privilege account (PR:L, AC:L, UI:N); confidentiality set to Low because exposure is bounded to the first 15 seconds per session, with no integrity or availability impact.

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

4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (GitHub_M).

CVSS VectorVendor: GitHub_M

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Lifecycle Timeline

Patch available

Jul 10, 2026 - 22:02 EUVD

Analysis Generated

Jul 10, 2026 - 21:38 vuln.today

DescriptionCVE.org

OpenReplay is a self-hosted session replay suite. From 1.22.0 before 1.27.0, getFirstMob returned 15-second presigned S3 download URLs for a session's DOM-replay recording based solely on the session path parameter, while validateProjectAccess checked only that the project belonged to the requester's tenant and did not verify that the session belonged to that project, allowing any authenticated low-privilege user to read another tenant's first 15 seconds of session-replay recording data. This issue is fixed in version 1.27.0.

AnalysisAI

Cross-tenant information disclosure in OpenReplay's self-hosted session-replay backend (versions 1.22.0 through 1.26.x) lets any authenticated low-privilege user retrieve the first 15 seconds of another tenant's DOM session-replay recording. The getFirstMob endpoint issued a 15-second presigned S3 URL keyed only on a user-supplied session path, while validateProjectAccess confirmed project-to-tenant ownership but never confirmed that the requested session actually belonged to that project, breaking multi-tenant isolation. No public exploit identified at time of analysis, but the flaw is trivially triggerable by any valid account and is fixed in 1.27.0.

Technical ContextAI

OpenReplay is an open-source, self-hosted session replay and product-analytics suite; replay data (DOM 'mob' recordings) is stored in S3-compatible object storage and served to the UI via short-lived presigned download URLs. The root cause is CWE-639 (Authorization Bypass Through User-Controlled Key), a classic IDOR: the session identifier is a client-controlled path parameter, and the server's authorization routine (validateProjectAccess) verified only that the caller's tenant owned the referenced project - it never enforced the session→project→tenant chain. Because the presigned S3 URL was generated from the unvalidated session path, the object-storage layer faithfully returned whatever session the attacker named, with S3 itself performing no tenant-level authorization.

RemediationAI

Vendor-released patch: upgrade to OpenReplay 1.27.0, which corrects the authorization check so that session ownership is validated against the project (and thus tenant) before a presigned S3 URL is issued; the fix is in PR https://github.com/openreplay/openreplay/pull/4692 and commit ddd09117f644a309c7b040cda0a11ff9433e9e49, with details in advisory https://github.com/openreplay/openreplay/security/advisories/GHSA-w2x5-m7w5-479h. If immediate upgrade is not possible, compensating controls include restricting the replay/session-download API (the getFirstMob route) at a reverse proxy or WAF to trusted internal networks, and - in strict single-tenant deployments - this cross-tenant issue is not exploitable, so isolating each customer to a dedicated instance removes the risk at the cost of higher operational overhead. Because the leak is bounded and confidentiality-only, avoid disruptive controls; monitor object-storage/presigned-URL access logs for anomalous session-path enumeration until patched.