CVE-2026-45297
Cross-Tenant IDOR in OpenReplay Feature-Flag Routes
Publication date: 2026-05-28
Last updated on: 2026-05-28
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| openreplay | openreplay | to 1.26.0 (exc) |
| openreplay | openreplay | 1.23.0 |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-285 | The product does not perform or incorrectly performs an authorization check when an actor attempts to access a resource or perform an action. |
| CWE-639 | The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data. |
| CWE-863 | The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-45297 is a cross-tenant Insecure Direct Object Reference (IDOR) vulnerability in OpenReplay versions 1.23.0 and earlier. It occurs due to a case mismatch in the project identifier parameter, allowing authenticated users in one tenant to access, modify, or delete feature flags and assist-stats data belonging to another tenant by manipulating the project_id value.
The authorization check only runs when the project identifier is in camelCase ("projectId"), which bypasses tenant isolation in multi-tenant environments. Attackers can iterate through sequential project IDs and feature flag IDs to exfiltrate sensitive data such as flag keys, payloads containing personally identifiable information (PII), and session analytics.
The open-source version is single-tenant and not directly impacted, but the enterprise edition with multi-tenant support is vulnerable. The issue was fixed in version 1.26.0.
How can this vulnerability impact me? :
This vulnerability allows an authenticated user in one tenant to read, update, or delete feature flags and assist-stats data belonging to another tenant by exploiting the project_id parameter.
As a result, sensitive information such as feature flag keys, payloads containing personally identifiable information (PII), and session analytics can be exposed or manipulated by unauthorized parties.
This can lead to data leakage, unauthorized data modification, and potential disruption of service or analytics integrity across tenants in a multi-tenant environment.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring requests to the feature-flag and assist-stats routes that include the project identifier parameter. Specifically, look for requests where the project identifier parameter is not in camelCase (i.e., using project_id instead of projectId), as this triggers the authorization bypass.
To detect exploitation attempts, you can analyze logs or network traffic for authenticated users accessing or attempting to access feature flags or assist-stats data belonging to other tenants by iterating through sequential project IDs and feature flag IDs.
Suggested commands include using network monitoring tools like tcpdump or Wireshark to capture HTTP requests to the vulnerable endpoints, or using grep on server logs to find suspicious requests with project_id parameters in non-camelCase form.
- Example grep command to find suspicious requests in logs: grep -E 'feature-flag|assist-stats' /path/to/access.log | grep 'project_id='
- Use curl or similar tools to test the endpoints with different casing of the project identifier parameter to verify if authorization checks are bypassed.
What immediate steps should I take to mitigate this vulnerability?
The immediate mitigation step is to upgrade OpenReplay to version 1.26.0 or later, where this vulnerability has been fixed.
Until the upgrade can be performed, restrict access to the feature-flag and assist-stats routes to trusted users only, and monitor for suspicious activity involving cross-tenant access attempts.
Additionally, review and enforce strict authorization checks on project identifiers, ensuring that tenant isolation is properly maintained regardless of parameter casing.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability allows authenticated users in one tenant to access, modify, or delete feature flags and assist-stats data belonging to another tenant by exploiting a cross-tenant IDOR issue. This can lead to unauthorized exposure and manipulation of sensitive data, including payloads containing personally identifiable information (PII) and session analytics.
Such unauthorized access and potential data leakage can negatively impact compliance with data protection regulations like GDPR and HIPAA, which require strict controls on data access and protection of personal data.