Description

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 Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-08-21T11:17:07.283Z",
  "pubdate": "2026-08-21T11:17:07.283Z",
  "executiveSummary": "An Insecure Direct Object Reference (IDOR) or Broken Object Level Authorization (BOLA) vulnerability exists in the report.get procedure within the packages/trpc/src/routers/report.ts component. This flaw allows any authenticated user to read arbitrary report configurations across the entire application instance by supplying a targeted report identifier.\nThe vulnerability impacts confidentiality by exposing sensitive configuration data, including owning project identifiers, event series, filters, breakdowns, and formulas. Exploitation requires only a valid authenticated session on the platform and knowledge of, or the ability to enumerate, valid report identifiers. Unlike adjacent procedures such as update, delete, and duplicate which properly enforce project-level access controls, the read procedure completely lacks proper resource scoping and authorization checks.\nThe root cause stems from conditional logic in the access control middleware that assumes authorization context must be explicitly provided via specific payload keys rather than derived server-side from the requested resource. Remediation requires implementing robust resource-level scoping and authorization checks within the affected procedure to ensure callers possess valid access to the parent project associated with the requested report.",
  "technicalDetails": "The vulnerability resides in the packages/trpc/src/routers/report.ts file where the report.get procedure accepts solely a reportId parameter as input and directly executes the getReportById(reportId) database query without validating whether the authenticated user holds valid membership or permissions over the target resource.\nAuthorization is handled globally via the enforceAccess middleware located in packages/trpc/src/trpc.ts. This middleware evaluates organization and project membership strictly when the incoming procedure input payload contains either a projectId or an organizationId key. Because the report.get procedure takes exclusively a reportId, the input payload lacks these required structural keys, causing the access enforcement middleware to bypass membership evaluation entirely.\nUpon bypassing middleware checks, the execution flow proceeds to the getReportById function defined in packages/db/src/services/reports.service.ts. This service executes an unfiltered database query via findUnique using only the provided report id with absolute zero project scoping or tenancy isolation checks.\nThe step-by-step attack flow involves an authenticated attacker crafting a request to the report.get tRPC endpoint containing an arbitrary reportId. Because no project or organization keys are present in the input, the enforceAccess middleware allows the request to pass unchecked. The database service subsequently retrieves and returns the full report configuration payload to the unauthorized user.\nThe impact allows any standard authenticated user to extract sensitive operational data belonging to other projects and organizations, including internal project identifiers, custom event series, analytical filters, data breakdowns, and proprietary formulas. This contrasts with adjacent administrative procedures like update, delete, and duplicate, which correctly resolve the parent project of the target report and enforce proper project access controls via getProjectAccess."
}