CVE-2026-77769 in Openpanel
Summary
by MITRE • 08/21/2026
The report.list procedure in packages/trpc/src/routers/report.ts accepted a projectId and a dashboardId and returned getReportsByDashboardId(dashboardId). The enforceAccess middleware in packages/trpc/src/trpc.ts verified membership for the supplied projectId, but nothing verified that the supplied dashboardId belonged to that project, and getReportsByDashboardId in packages/db/src/services/reports.service.ts selects reports by dashboardId alone with no project scoping. An authenticated user could therefore pair a projectId from their own organization, which satisfies the middleware, with a dashboardId belonging to another organization and receive every report in that dashboard. A correctly scoped helper, listReportsCore, already existed in the same service file and resolves the dashboard through getDashboardById(dashboardId, projectId) before returning reports, but the router did not use it.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/21/2026
The vulnerability described constitutes a critical Insecure Direct Object Reference (IDOR), classified under CWE-639, which allows an authenticated attacker to access resources belonging to other users or organizations by manipulating input parameters. The root cause lies in a flawed authorization logic within the backend API implementation for report retrieval. Specifically, the list procedure accepts two distinct identifiers: a projectId and a dashboardId. While the system enforces strict membership verification against the provided projectId through middleware that ensures the user belongs to that specific project or organization, it completely fails to validate whether the supplied dashboardId is actually associated with that same projectId. This architectural oversight creates a security gap where access control checks are performed on one entity but applied incorrectly to another unrelated resource identifier.
From an operational perspective, this flaw enables unauthorized data exfiltration across organizational boundaries in multi-tenant environments. An attacker who has valid credentials for Organization A can simply substitute the dashboardId parameter with that of a target dashboard belonging to Organization B. Since the middleware only checks if the user is part of Project A, and the database query retrieves reports based solely on Dashboard ID without verifying project ownership, the system returns all sensitive report data contained within the external dashboard. This results in a complete bypass of multi-tenant isolation controls, potentially exposing confidential business intelligence, financial records, or proprietary metrics to unauthorized parties. The impact is severe as it undermines the fundamental trust model of SaaS applications that rely on strict tenant separation.
The technical details reveal that the service layer already contained a secure implementation pattern via a helper function named listReportsCore. This correct method explicitly resolves the dashboard context by calling getDashboardById with both the dashboardId and projectId, thereby ensuring ownership verification before returning any data. However, the public-facing router endpoint erroneously bypassed this secured logic in favor of a direct call to getReportsByDashboardId, which lacks project scoping entirely. This indicates either an oversight during development or a failure to enforce consistent use of secure helper functions across different endpoints within the codebase. The presence of the correct implementation highlights that the vulnerability is not due to missing capability but rather incorrect application logic in the specific API route exposed to users.
To mitigate this vulnerability, immediate remediation requires refactoring the list procedure to utilize the existing listReportsCore function or implementing equivalent project-scoped validation directly within the endpoint. The database query must be updated to include a join or filter condition that links dashboardId with projectId, ensuring that reports are only returned if they belong to dashboards owned by the authenticated user's organization. Additionally, defensive programming practices should be enforced through code reviews and static analysis tools to prevent similar mismatches between middleware checks and service-level logic in other endpoints. Long-term improvements include implementing a centralized authorization policy engine or using framework-specific decorators that automatically enforce object ownership verification for all resource access operations, thereby reducing the risk of manual errors in permission checking logic. This incident aligns with ATT&CK technique T1078, Valid Accounts, as it leverages legitimate credentials to perform unauthorized data access due to insufficient validation controls.