Cross-tenant IDOR on feature-flag and assist-stats routes via {project_id} case mismatch
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.
- Products
- Not specified
- Affected versions
- Not specified
- Fixed versions
- Not specified
- CVEs
- CVE-2026-45297
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 4 Nov 2026, 03:25 UTC · Revision 1
Source evidence
Cross-tenant IDOR on feature-flag and assist-stats routes via {project_id} case mismatch
core-osv · Original sourcePublished 28 May 2026, 16:50 UTC
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.
osv:CVE-2026-45297
Complete source record
{
"id": "843fdd2a96c77bcf93d674430515ab3afd41d43b129079a23ae2f6fa28f66bc0",
"url": "https://osv.dev/vulnerability/CVE-2026-45297",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "Cross-tenant IDOR on feature-flag and assist-stats routes via {project_id} case mismatch",
"summary": "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.",
"evidence": "osv:CVE-2026-45297",
"products": [],
"severity": "medium",
"structured": {
"id": "CVE-2026-45297",
"aliases": [
"CVE-2026-45297",
"GHSA-5m23-rcj4-cgjx"
],
"metrics": [
{
"type": "CVSS_V4",
"score": "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"
}
],
"affected": [
{
"ranges": [
{
"repo": "https://github.com/openreplay/openreplay",
"type": "GIT",
"events": [
{
"introduced": "0"
},
{
"fixed": "f450d5dbc689f15ea803ee864b5c598f3f013c6d"
}
],
"database_specific": {
"extracted_events": [
{
"range": [
{
"introduced": "0"
},
{
"fixed": "1.26.0"
}
],
"source": "AFFECTED_FIELD",
"strategy": "StringRangeExpression"
},
{
"range": [
{
"introduced": "0"
},
{
"fixed": "1.26.0"
}
],
"source": "DESCRIPTION"
}
]
}
}
],
"versions": [
"pre-v1.26.0",
"pre-v1.25.0",
"pre-v1.24.0",
"0.6.17",
"or-argo-test",
"pre-v1.22.0",
"pre-v1.21.0",
"pre-v1.20.0",
"v0.5.0",
"pre-v1.19.0",
"argo",
"pre_v1.18.0",
"v.1.14.0",
"v1.9.0",
"v1.5.2",
"v1.5.1",
"v1.5.0",
"v1.4.0",
"v1.3.6",
"v1.3.0",
"v1.2.0",
"v1.1.0",
"v1.0.0"
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-45297.json"
}
}
],
"modified": "2026-10-28T02:30:32.980173106Z",
"provider": "osv",
"references": [
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/45xxx/CVE-2026-45297.json",
"https://github.com/openreplay/openreplay/security/advisories/GHSA-5m23-rcj4-cgjx",
"https://nvd.nist.gov/vuln/detail/CVE-2026-45297"
],
"provider_metadata": {
"cwe_ids": [
"CWE-285",
"CWE-639",
"CWE-863"
],
"cna_assigner": "GitHub_M",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/45xxx/CVE-2026-45297.json"
}
},
"related_cves": [
{
"value": "CVE-2026-45297",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": "/severity/0/score"
},
"source_id": "core-osv",
"document_id": 500018,
"published_at": "2026-05-28T16:50:38.672+00:00"
}