Description

Openpanel before 2.3.0 contains an insecure direct object reference vulnerability in the report.getLayouts and report.resetLayout tRPC procedures that fail to bind dashboardId to the authorized projectId. Authenticated attackers can supply an arbitrary victim dashboardId with their own projectId to read report layouts and configurations or delete dashboard grid arrangements across tenants.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.4",
  "pubDate": "2026-09-04T12:17:25.130Z",
  "pubdate": "2026-09-04T12:17:25.130Z",
  "executiveSummary": "Openpanel versions prior to 2.3.0 are susceptible to an Insecure Direct Object Reference (IDOR) vulnerability within its tRPC API layer. The flaw specifically affects the report.getLayouts and report.resetLayout procedures, where the application fails to perform adequate server-side authorization checks between the user-provided dashboardId and the session-associated projectId.\nThis vulnerability allows an authenticated attacker to perform unauthorized read and write operations across tenant boundaries. By manipulating the dashboardId parameter in API requests, a malicious actor can access sensitive report configurations or destructively reset dashboard grid layouts belonging to other users. The risk is significant as it facilitates unauthorized data access and potential service disruption without requiring elevated administrative privileges, provided the attacker maintains a valid authenticated session within the platform.",
  "technicalDetails": "The vulnerability originates from an improper access control implementation within the tRPC communication layer of Openpanel. Specifically, the procedures report.getLayouts and report.resetLayout fail to implement a strict verification mechanism to bind the requested dashboardId to the authenticated user's authorized projectId. Under normal operation, the application should validate that the provided dashboardId belongs to a project associated with the current session's security context. Instead, the backend logic trusts the user-supplied input without verifying resource ownership, leading to an IDOR condition.\nExploitation follows a predictable flow: an authenticated attacker initiates a request to the tRPC endpoint targeting one of the vulnerable procedures. By iterating through potential dashboardId values—often sequential or predictable integers or UUIDs—the attacker can bypass the intended logical silo. For report.getLayouts, the server returns the requested layout data, potentially exposing internal configuration details, widget arrangements, and data visualization settings of arbitrary tenants. For report.resetLayout, the lack of ownership verification allows the attacker to trigger a deletion or reset of the grid arrangement for any target dashboardId, effectively causing a loss of availability regarding the victim's dashboard configuration.\nThis flaw is strictly a server-side authorization failure. The vulnerable component is the tRPC controller responsible for handling report management functions. Authentication is required to reach the vulnerable procedures, meaning the attacker must be a registered, logged-in user within the Openpanel ecosystem; however, no specific administrative or privileged role is required, as standard user accounts possess the necessary access to invoke the report endpoints. The attack is fully reachable over the network and does not require complex payloads, only the modification of the request parameters to reference objects outside the attacker's assigned scope. Post-exploitation, the attacker gains the ability to map the dashboard infrastructure of other tenants and perform unauthorized destructive actions, compromising the confidentiality and integrity of the platform's multi-tenant data architecture."
}