CVE-2026-77769 Openpanel-dev CVE debrief

Who should care

Administrators and users of Openpanel-dev openpanel, especially those managing reports and dashboards across multiple organizations, should verify their configurations and restrict access to prevent unauthorized report retrieval. They should also monitor for suspicious report retrieval patterns and implement proper scoping for getReportsByDashboardId. Additionally, they should review compensating controls for exposed systems while remediation is scheduled and verified, and track exceptions, retest remediated assets, and close the item only after evidence is documented.

Technical summary

The report.list procedure in packages/trpc/src/routers/report.ts did not properly verify that the dashboardId belonged to the projectId provided, allowing an authenticated user to retrieve reports from another organization by pairing a valid projectId with a dashboardId from a different organization. This issue arises from the lack of proper scoping in getReportsByDashboardId in packages/db/src/services/reports.service.ts, which selects reports by dashboardId alone without project scoping. The enforceAccess middleware in packages/trpc/src/trpc.ts verified membership for the supplied projectId but not the dashboardId. 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. To fix this, the report.list procedure should use the listReportsCore helper to ensure proper scoping and verification of dashboardId ownership.

Defensive priority

Authenticated users with project access may be able to retrieve reports from other organizations by manipulating dashboardIds.

Recommended defensive actions

• Verify project and dashboardId validation in report.list procedure
• Implement proper scoping for getReportsByDashboardId
• Use existing listReportsCore helper for correct dashboard resolution
• Restrict report access based on authenticated user's organization membership
• Monitor for suspicious report retrieval patterns
• Review compensating controls for exposed systems while remediation is scheduled and verified
• Track exceptions, retest remediated assets, and close the item only after evidence is documented

Evidence notes

The report.list procedure did not verify that the supplied dashboardId belonged to the projectId provided, allowing potential unauthorized access to reports across organizations. This issue arises from insufficient validation in the report.list procedure in packages/trpc/src/routers/report.ts, where the enforceAccess middleware only verified membership for the supplied projectId but not the dashboardId. Consequently, an authenticated user could pair a projectId from their own organization 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. To address this, defenders should verify their configurations, restrict access to prevent unauthorized report retrieval, and monitor for suspicious report retrieval patterns.

Official resources