PatchSiren

PatchSiren cyber security CVE debrief

CVE-2026-45297 openreplay CVE debrief

OpenReplay is a self-hosted session replay suite. Prior to version 1.26.0, the Enterprise Edition (EE) contains an insecure direct object reference (IDOR) vulnerability on feature-flag and assist-stats routes. The ProjectAuthorizer authorization check in ee/api/auth/auth_project.py only validates tenant-project-user relationships when the project identifier uses camelCase (projectId). For routes using other case variants, the authorization check is bypassed. Additionally, EE feature-flag queries filter only on project_id without tenant_id validation. This allows any authenticated user in one tenant to read, update, or delete feature-flag data belonging to other tenants by iterating sequential integer identifiers. The Open Source Software (OSS) edition is single-tenant by design and not affected by cross-tenant attacks. The vulnerability is fixed in OpenReplay 1.26.0.

Vendor
openreplay
Product
Unknown
CVSS
MEDIUM 5.3
CISA KEV
Not listed in stored evidence
Original CVE published
2026-05-28
Original CVE updated
2026-05-28
Advisory published
2026-05-28
Advisory updated
2026-05-28

Who should care

Organizations running OpenReplay Enterprise Edition (EE) in multi-tenant configurations should prioritize this patch. Security teams responsible for SaaS session replay platforms, DevOps engineers managing OpenReplay deployments, and compliance officers overseeing tenant data isolation requirements should assess exposure and apply remediation. Organizations using the OSS single-tenant edition are not affected by cross-tenant data access but should still upgrade as part of standard security hygiene.

Technical summary

The vulnerability stems from case-sensitive string matching in the ProjectAuthorizer authorization middleware. When the project identifier parameter does not exactly match projectId (camelCase), the authorization check that validates tenant_id, project_id, and user_id relationships is skipped entirely. In the EE multi-tenant architecture, downstream feature-flag database queries filter only on project_id, never validating that the requesting user's tenant_id matches the data's tenant ownership. This architectural gap permits authenticated users to access and modify other tenants' feature-flag configurations by supplying arbitrary sequential project_id values. The OSS edition prevents this attack vector through its single-tenant design, which rejects additional tenant registrations.

Defensive priority

medium

Recommended defensive actions

  • Upgrade OpenReplay to version 1.26.0 or later to remediate the cross-tenant IDOR vulnerability.
  • For deployments unable to upgrade immediately, review and restrict network access to OpenReplay EE instances to authorized administrative users only.
  • Audit feature-flag and assist-stats access logs for anomalous cross-tenant access patterns, particularly sequential enumeration of project_id and feature_flag_id values.
  • Verify that custom integrations or API clients use the exact projectId camelCase identifier to ensure proper authorization enforcement.
  • Review tenant isolation controls in multi-tenant OpenReplay EE deployments to confirm no residual authorization bypass conditions exist.

Evidence notes

The vulnerability description indicates the authorization bypass occurs in ProjectAuthorizer.__call__ at ee/api/auth/auth_project.py:14-46, where projects.is_authorized() and projects.get_project() are only invoked when self.project_identifier == projectId. For other identifier cases, tenant validation is skipped. The EE feature-flag routes lack tenant_id filtering, enabling cross-tenant access via sequential ID enumeration.

Official resources

2026-05-28