CVE-2026-85611 in OpenPanel
Summary
by MITRE • 09/04/2026
OpenPanel before 2.3.0 contains a cross-tenant broken object level authorization vulnerability in the report.getLayouts and report.resetLayout tRPC procedures that fail to scope dashboard queries to the caller's project. Authenticated attackers can supply their own projectId with a victim organization's guessable dashboardId to read confidential report definitions or permanently delete dashboard layouts across tenant boundaries.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/04/2026
The vulnerability identified in OpenPanel versions prior to 2.3.0 represents a critical failure in access control mechanisms, specifically classified as a Broken Object Level Authorization (BOLA) issue within the application's API layer. This flaw resides primarily in two tRPC procedures: report.getLayouts and report.resetLayout. These endpoints are designed to retrieve or modify dashboard configurations for users who have authenticated into the system. However, the implementation fails to enforce proper tenant isolation by not validating that the requested resource belongs to the same organization as the authenticated user. Instead of deriving the project context from the session token or server-side state, the application relies on client-supplied input parameters without sufficient verification against the caller's authorized scope. This architectural oversight allows an attacker who has valid credentials for one tenant to interact with resources belonging to another tenant by manipulating request payloads.
From a technical perspective, the exploitation vector involves supplying a projectId associated with a victim organization alongside a dashboardId that is either known or easily guessable within that target environment. Because the backend logic does not cross-reference these identifiers against the authenticated user's permissions, it proceeds to execute the requested operation on the specified resource regardless of ownership. In the case of report.getLayouts, this results in unauthorized data exfiltration where confidential report definitions and dashboard layouts can be read by an external party. For the report.resetLayout procedure, the impact is more severe as it permits the permanent deletion or alteration of critical UI configurations across tenant boundaries. This lack of object-level authorization control effectively bypasses multi-tenancy security models, treating all accessible resources as public to any authenticated user who knows the resource identifiers.
The operational impact of this vulnerability extends beyond simple data leakage to include significant integrity and availability risks for organizations using OpenPanel. Attackers can harvest sensitive business intelligence embedded in report definitions, which may contain proprietary metrics, customer data insights, or strategic planning documents. Furthermore, the ability to reset layouts disrupts ongoing operations by removing customized views that teams rely on for daily monitoring and analysis. This degradation of service affects productivity and trust in the platform's security posture. The ease of exploitation is heightened because dashboard identifiers are often sequential or predictable, allowing attackers to enumerate valid targets with minimal effort once they have obtained a single set of legitimate credentials from any tenant within the ecosystem.
This vulnerability aligns closely with CWE-639, which describes Authorization Bypass Through User-Controlled Key, and maps directly to MITRE ATT&CK technique T1078, Valid Accounts, as it leverages existing authentication to perform unauthorized actions across boundaries. It also reflects aspects of CWE-284, Improper Access Control, where the system fails to restrict access to resources based on user roles or ownership. To mitigate this issue, organizations must upgrade immediately to OpenPanel version 2.3.0 or later, which addresses these authorization checks by enforcing strict tenant scoping for all dashboard-related API calls. Additionally, developers should implement server-side validation that verifies the authenticated user's organization ID against the project and dashboard IDs provided in every request, ensuring that cross-tenant access is explicitly denied unless authorized through proper administrative workflows. Regular security audits focusing on object-level authorization patterns are recommended to prevent similar flaws in future updates or custom integrations.