CVE-2026-77768 in Openpanel
Summary
by MITRE • 08/21/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/21/2026
The vulnerability identified in the trpc package represents a critical authorization bypass within the application logic for retrieving saved reports. Specifically, the getReportById function exposed through the packages/trpc/src/routers/report.ts endpoint fails to enforce proper access controls due to an incomplete implementation of middleware checks. The system relies on the enforceAccess middleware located in packages/trpc/src/trpc.ts to validate user permissions before allowing data retrieval or modification operations. However, this middleware is designed with a conditional logic flaw that only evaluates membership and authorization when the incoming input payload contains specific keys such as projectId or organizationId. When a request is made using solely a reportId parameter, these required keys are absent from the input object, causing the middleware to skip its security checks entirely. This oversight allows any authenticated user to bypass access restrictions by constructing requests that target reports directly via their unique identifiers without providing context about the associated project or organization.
The technical root cause lies in the asymmetry between how different operations handle authorization and data retrieval. While procedures for updating, deleting, or duplicating a report correctly resolve the full report object first and then invoke getProjectAccess to verify if the user has permission over the specific projectId linked to that report, the read operation does not follow this secure pattern. Instead, it passes the raw input directly to the database service layer in packages/db/src/services/reports.service.ts. This service executes a findUnique query based strictly on the provided reportId without applying any scoping constraints related to project ownership or tenant isolation. Consequently, the application returns the complete configuration of the requested report regardless of whether the requesting user has legitimate access rights to it. This design flaw effectively creates an insecure direct object reference scenario where internal identifiers are exposed and utilized for unauthorized data access.
The operational impact of this vulnerability is significant, as it allows any authenticated account on the instance to read sensitive configurations associated with saved reports owned by other users or organizations. The retrieved data includes detailed information such as the owning projectId, event series definitions, filter criteria, breakdown structures, and custom formulas. This exposure can lead to several adverse outcomes including intellectual property theft if proprietary analytical models are exposed, competitive intelligence leakage where business insights derived from filtered datasets become accessible to unauthorized parties, and potential facilitation of further attacks by revealing internal system architecture or data relationships that could be leveraged for more sophisticated exploitation attempts. The ability to enumerate valid report IDs also aids attackers in mapping the application's resource landscape even if they do not immediately understand the content within each report.
This vulnerability aligns with CWE-284, which describes Improper Access Control where insufficient authorization checks allow unauthorized access to resources. Furthermore, it maps directly to MITRE ATT&CK technique T1078, specifically Valid Accounts and potentially T1530 if used for data exfiltration from cloud storage or internal databases. The failure stems from a lack of consistent security middleware application across all endpoints, highlighting the importance of ensuring that read operations are subject to the same rigorous access verification as write operations. To mitigate this issue, developers must modify the enforceAccess middleware logic to ensure it evaluates authorization regardless of whether projectId or organizationId keys are present in the input payload. Alternatively, the getReportById procedure should be refactored to first resolve the report object using a secure method that includes ownership context and then perform an explicit access check against the resolved project before returning any data. Implementing these changes will ensure that all interactions with sensitive resources adhere to the principle of least privilege and prevent unauthorized disclosure of confidential business intelligence.