EUVD-2026-63901
GHSA-g8mq-qr24-3qv3
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate to OpenPanel instance
-
DeliveryObtain or guess target reportId
-
ExploitCall report.get tRPC procedure with reportId only
-
ExecutionenforceAccess middleware skips project check
-
PersistgetReportById returns full report object
-
ImpactAttacker reads cross-project analytics configuration
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Object-level authorization, IDOR prevention
|
| Exploitation Conditions | Exploitation requires a valid authenticated session on the target OpenPanel instance (PR:L per CVSS 4.0). The attacker must supply a known reportId; because IDs appear to be UUIDs, random enumeration is not practical - a realistic attacker obtains the ID through a shared link, referral, or insider access. The flaw is confined to the report.get tRPC procedure; the report.update, report.delete, and report.duplicate procedures all perform getProjectAccess checks against the report's projectId and are not affected. Multi-tenant deployments where users across different projects or organisations share one OpenPanel instance represent the primary risk scenario. Single-tenant deployments where all authenticated users already belong to the same project have no meaningful cross-boundary exposure from this flaw. |
| Impact | The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N) accurately characterises a network-exploitable flaw requiring only a valid authenticated session (PR:L) with high confidentiality impact and no integrity or availability impact. Attack complexity is genuinely low - the exploitation pattern is a single authenticated API call with a known or enumerated reportId. Report identifiers in OpenPanel appear to be UUIDs, so brute-force enumeration is impractical, but IDs can plausibly be obtained from shared dashboard URLs or application logging. No EPSS score was provided in the input data, and the vulnerability is not listed in CISA KEV, indicating no confirmed widespread exploitation at time of analysis. Real-world impact is highest in multi-tenant deployments where teams from different organisations share one instance, as their analytics configurations - potentially encoding proprietary KPIs, segmentation logic, and business-sensitive filter criteria - are mutually readable by any authenticated user. Single-tenant or single-organisation deployments face negligible cross-boundary exposure. |
| Exploit ScenarioDerived | An authenticated user on a shared OpenPanel instance obtains a target reportId - for example, extracted from a dashboard share link sent by a colleague in a different project - and issues a direct tRPC call to report.get with that identifier. The server returns the complete report object including event series, breakdowns, and formula definitions belonging to the foreign project, with no authorization error. No public exploit code has been identified, but the technique requires only standard HTTP tooling and knowledge of the tRPC endpoint structure. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Aug 21, 2026
Insecure direct object reference in OpenPanel's tRPC report.get procedure exposes any saved report's full configuration to any authenticated instance user. The enforceAccess middleware in packages/trpc/src/trpc.ts conditionally evaluates project membership only when the input carries a projectId or organizationId key; since report.get accepted only a reportId, it bypassed all authorization checks, and the underlying getReportById query performed no project-level scoping. No public exploit or active exploitation (CISA KEV) has been identified at time of analysis, though the attack pattern is trivially reproducible by any authenticated developer familiar with tRPC.
RemediationAI
The upstream fix is available in commit 0a51b6805eed0b3da8376175acd5fa3d26819cb6 (https://github.com/Openpanel-dev/openpanel/commit/0a51b6805eed0b3da8376175acd5fa3d26819cb6), which adds a getProjectAccess call immediately after fetching the report in report.get and throws a TRPCForbiddenError if the authenticated user lacks membership in the report's owning project. Operators should upgrade to a release incorporating this commit; no specific patched release version number was confirmed in the available data, so the GitHub advisory at https://github.com/Openpanel-dev/openpanel/security/advisories/GHSA-9x7c-f87x-2243 should be consulted for the canonical fixed version. As a compensating control prior to patching, operators can restrict network-layer access to the tRPC API so that only users within the same organisational boundary can reach report.get endpoints; this reduces cross-tenant exposure but does not eliminate the flaw for same-instance multi-tenant configurations and may break legitimate cross-team workflows.
Affected VersionsENISA
Affects your stack
Find out whether the stacks and servers you run are on an affected version.
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
OpenPanel is an open-source product analytics platform whose backend API is built on tRPC. The root cause (CWE-639: Authorization Bypass Through User-Controlled Key) is an architectural gap in the enforceAccess middleware located at packages/trpc/src/trpc.ts: the middleware gates project membership checks on the presence of a projectId or organizationId key in the procedure input. The report.get procedure at packages/trpc/src/routers/report.ts was defined to accept only a reportId input, so it never triggered that gate. The downstream data access function getReportById in packages/db/src/services/reports.service.ts executes a Prisma findUnique on the report ID alone with no project-scoped WHERE clause, returning the complete report object - including owning projectId, event series, filters, breakdowns, and formulas - to any caller that reaches it. Adjacent procedures (update, delete, duplicate) resolve the report first and then explicitly call getProjectAccess against the report's own projectId, confirming the omission was isolated to the get procedure.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
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
Network-exploitable IDOR requiring an authenticated session (PR:L); high confidentiality impact as complete report configurations are disclosed, with no integrity or availability impact and no scope change.
Primary rating from Vendor (vulncheck).
CVSS VectorVendor: vulncheck
Lifecycle Timeline
2DescriptionCVE.org
The report.get procedure in packages/trpc/src/routers/report.ts accepted only a reportId and returned getReportById(reportId) directly. The enforceAccess middleware in packages/trpc/src/trpc.ts evaluates membership only when the input carries a projectId or organizationId key, so an input consisting of a reportId alone passed through unchecked, and getReportById in packages/db/src/services/reports.service.ts performs a findUnique on the report id with no project scoping. Any authenticated user could therefore read the full configuration of any saved report on the instance, including the owning projectId, event series, filters, breakdowns and formulas, by supplying its identifier. The adjacent update, delete and duplicate procedures resolve the report first and check getProjectAccess against the report's own projectId, so the omission was specific to this procedure.
Executive ViewAI
OpenPanel's report.get function contains an authorization bypass allowing any authenticated user to access all saved reports and their full configurations, regardless of role or project membership. No public exploit has been identified at time of analysis, but this trivial attack pattern creates a high-risk data exposure affecting all users with instance access. Without a released patch, immediate access controls are required to limit exposure until the vendor provides remediation.
No vendor-released patch identified at time of analysis. Interim mitigations: (1) restrict OpenPanel instance access to only personnel with legitimate business need for full report visibility; (2) audit and monitor access logs for report.get API calls to detect unauthorized viewing patterns; (3) implement network-level access controls to limit OpenPanel connectivity; (4) if operationally feasible, temporarily disable report.get functionality; (5) engage with OpenPanel development team to implement additional application-level authorization checks validating project membership before returning report data.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
Exploit-DB