Is there a patch available for CVE-2026-45297?

Yes, a patch is available for CVE-2026-45297. Update the affected software to the latest version immediately.

OpenReplay CVE-2026-45297

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

CVE-2026-45297 has a CVSS 4.0 base score of 5.3 (Medium). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/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.0%.

EUVD-2026-32970 MEDIUM

Improper Authorization (CWE-285)

2026-05-28 GitHub_M

Authentication Bypass Openreplay

5.3

CVSS 4.0 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

5.3 MEDIUM

CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/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

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

CVSS VectorGitHub Advisory

CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/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

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Lifecycle Timeline

Analysis Generated

May 28, 2026 - 20:26 vuln.today

Patch available

May 28, 2026 - 19:02 EUVD

CVSS changed

May 28, 2026 - 18:22 NVD

5.3 (MEDIUM)

CVE Published

May 28, 2026 - 16:50 nvd

UNKNOWN (no severity yet)

DescriptionGitHub Advisory

OpenReplay is a self-hosted session replay suite. Prior to 1.26.0, there is a cross-tenant IDOR on feature-flag and assist-stats routes via {project_id} case mismatch. ProjectAuthorizer.__call__ (OSS api/auth/auth_project.py:14-38 and EE ee/api/auth/auth_project.py:14-46) only runs projects.is_authorized(project_id, tenant_id, user_id) + projects.get_project(tenant_id, project_id) when self.project_identifier == "projectId" (camelCase). For EE multi-tenant, feature-flag queries only filter on project_id, never tenant_id. Any authenticated user in tenant A can read/update/delete feature-flag rows belonging to tenant B by iterating the sequential integer project_id + feature_flag_id. OSS is single-tenant by design ({"errors":["tenants already registered"]} on second signup) so there's no cross-tenant impact This vulnerability is fixed in 1.26.0.

AnalysisAI

Cross-tenant Insecure Direct Object Reference (IDOR) in OpenReplay Enterprise Edition allows any authenticated user from one tenant to read, update, or delete feature-flag and assist-stats data belonging to another tenant. The vulnerability exists because ProjectAuthorizer skips its tenant-scoped authorization check when the route parameter does not exactly match the camelCase string 'projectId', and EE feature-flag queries filter only on project_id without enforcing tenant_id isolation. Affecting all EE multi-tenant deployments prior to 1.26.0, no public exploit code has been identified at time of analysis, though the sequential integer ID scheme makes enumeration trivially feasible for any authenticated attacker.

Technical ContextAI

OpenReplay is a self-hosted session replay suite with an Enterprise Edition (EE) supporting multi-tenancy. The authorization layer in both OSS (api/auth/auth_project.py:14-38) and EE (ee/api/auth/auth_project.py:14-46) is implemented via a ProjectAuthorizer callable class. The flaw is a string comparison gate: full tenant-scoped authorization (projects.is_authorized + projects.get_project with tenant_id) only executes when self.project_identifier equals the exact camelCase string 'projectId'. Routes using a differently-cased or alternate parameter name bypass this check entirely. Compounding the issue, EE database queries for feature-flag rows are not scoped to tenant_id at the query level, meaning authorization enforcement is entirely dependent on the middleware layer that can be bypassed. CWE-285 (Improper Authorization) is the root cause - the authorization logic relies on a fragile string-match condition rather than enforcing tenant isolation at the data layer. Affected CPE: cpe:2.3:a:openreplay:openreplay:*:*:*:*:*:*:*:* for all versions prior to 1.26.0. The OSS edition is explicitly not affected because it is architecturally single-tenant (enforced at registration time).

RemediationAI

The vendor-released patch is OpenReplay version 1.26.0, which resolves the case-mismatch authorization bypass and enforces tenant_id scoping on feature-flag queries. Operators running EE multi-tenant deployments should upgrade to 1.26.0 immediately; the advisory is available at https://github.com/openreplay/openreplay/security/advisories/GHSA-5m23-rcj4-cgjx. As a compensating control prior to patching, administrators can restrict access to feature-flag and assist-stats API routes at the reverse proxy or API gateway layer so that only requests from a tenant's own known IP ranges or authenticated sessions with verified tenant context can reach those endpoints - though this may impact legitimate cross-origin or API-client use cases. Audit logs for feature-flag and assist-stats routes should be reviewed for anomalous project_id enumeration patterns (sequential integer access across a wide range of IDs from a single user/session) to identify potential prior exploitation. Do not rely on application-layer rate limiting alone, as the bypass occurs before the authorization check executes.