Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-08-21T11:17:07.430Z",
  "pubdate": "2026-08-21T11:17:07.430Z",
  "executiveSummary": "An Insecure Direct Object Reference (IDOR) and broken access control vulnerability exists in the report.list procedure within packages/trpc/src/routers/report.ts. The flaw allows authenticated users to bypass organizational data boundaries and retrieve unauthorized reports by manipulating parameters.\nThe vulnerability impacts multi-tenant data confidentiality by enabling horizontal privilege escalation. An authenticated attacker can read sensitive report data belonging to other organizations by pairing an authorized projectId from their own organization with an arbitrary dashboardId belonging to a victim organization.\nAlthough an authentication boundary is enforced via the enforceAccess middleware in packages/trpc/src/trpc.ts, it only validates membership against the supplied projectId. The underlying database query executed by getReportsByDashboardId in packages/db/src/services/reports.service.ts fails to perform secondary validation confirming that the requested dashboardId correlates to the verified projectId.\nExploitation requires active authentication within the system and the ability to craft or intercept tRPC procedure calls containing mismatched project and dashboard identifiers. A secure, correctly scoped helper function named listReportsCore already exists within the codebase but was omitted from the vulnerable router implementation.",
  "technicalDetails": "The root cause of the vulnerability is a failure of defense-in-depth and context-aware authorization checking within the tRPC routing layer. The report.list procedure accepts both a projectId and a dashboardId as input parameters. The authorization middleware, enforceAccess located in packages/trpc/src/trpc.ts, correctly validates that the authenticated user maintains membership within the provided projectId. However, this check is insufficient because it creates a false sense of security for subsequent operations.\nFollowing the middleware execution, the procedure delegates data retrieval to the getReportsByDashboardId function located in packages/db/src/services/reports.service.ts. This database service function executes a query that filters reports exclusively by the supplied dashboardId, completely omitting any project scoping or relational checks to ensure the dashboard actually belongs to the validated projectId.\nThe attack flow proceeds as follows: First, an authenticated user obtains a valid projectId from an organization they legitimately belong to, ensuring that the enforceAccess middleware validation succeeds. Second, the user submits a crafted tRPC request to the report.list procedure containing their valid projectId coupled with a target dashboardId belonging to a completely different organization. Third, because the middleware only inspects the projectId, the request passes the authorization check. Finally, the un-scoped getReportsByDashboardId function executes against the database, returning every report associated with the foreign dashboardId to the unauthorized user.\nThe vulnerability is compounded by the fact that a secure alternative, listReportsCore, already exists within packages/db/src/services/reports.service.ts. This helper function properly resolves the dashboard hierarchy via getDashboardById(dashboardId, projectId) prior to fetching reports, thereby enforcing proper multi-tenant isolation. The failure to invoke this secure core function within packages/trpc/src/routers/report.ts directly results in the exposure of cross-organization analytics and reporting data."
}