CVE-2026-92539 in Grafana
Summary
by MITRE • 10/20/2026
A service account with user-management permissions in one organization can read, modify, disable or delete users belonging to other organizations on the same Grafana instance through the SCIM API (insecure direct object reference). Only Grafana Enterprise instances with SCIM enabled are affected.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/20/2026
The vulnerability described constitutes a critical Insecure Direct Object Reference (IDOR) flaw within the System for Cross-domain Identity Management (SCIM) API implementation of Grafana, specifically affecting enterprise editions where this feature is active. This security lapse allows an attacker possessing service account credentials with user-management permissions in one tenant organization to bypass logical access controls and interact directly with resources belonging to other distinct organizations hosted on the same multi-tenant instance. By manipulating resource identifiers within SCIM API requests, a compromised or maliciously configured service account can read sensitive profile data, modify user attributes, disable accounts, or permanently delete users across organizational boundaries that should remain strictly isolated from one another.
From a technical perspective, this flaw stems from insufficient server-side validation of the organization context when processing SCIM operations. While Grafana’s multi-tenancy model is designed to enforce strict separation between organizations, ensuring that data and administrative actions are confined within their respective tenants, the SCIM API endpoint fails to adequately bind the authenticated service account's organizational scope to the target resource identifier provided in the request payload. Consequently, if an attacker can predict or enumerate valid user identifiers from a different organization, they can construct HTTP requests targeting those specific objects without triggering authorization errors that would normally prevent cross-tenant access. This represents a fundamental failure in enforcing object-level permissions relative to the tenant context.
The operational impact of this vulnerability is severe due to its potential for widespread data exfiltration and service disruption across multiple tenants sharing a single Grafana instance. An attacker can harvest personally identifiable information, email addresses, and other profile details from users in unrelated organizations, leading to significant privacy violations and compliance failures under regulations such as GDPR or HIPAA depending on the nature of the data stored. Furthermore, the ability to disable or delete user accounts enables denial-of-service attacks against specific teams or entire departments within those organizations, disrupting business continuity and potentially masking further malicious activities by removing audit trails associated with active users. The lack of isolation means that a compromise in one low-privilege service account can escalate into a full-scale breach affecting the integrity and availability of data for all other tenants on the platform.
This vulnerability aligns closely with CWE-639, which categorizes issues related to authorization bypasses via direct object references where the application relies on client-supplied input without sufficient server-side validation against access control policies. In terms of offensive security frameworks, this behavior maps to MITRE ATT&CK technique T1078, specifically Valid Accounts and potentially T1530 if data is exfiltrated from cloud storage or multi-tenant environments. The exploitation vector typically involves crafting custom API calls using tools like curl or Python scripts after obtaining valid service account credentials through phishing, credential stuffing, or other initial access methods targeting the less secure organization.
Mitigation strategies must prioritize immediate patching to the latest version of Grafana Enterprise where this IDOR flaw has been addressed by enforcing strict tenant-context validation on all SCIM API endpoints. Administrators should also implement network-level controls such as Web Application Firewalls (WAF) that can detect anomalous patterns in API requests, particularly those involving cross-tenant resource IDs. Additionally, adopting the principle of least privilege is essential; service accounts with user-management permissions should be restricted to only the specific organizational scopes they require rather than having broad administrative capabilities across the entire instance. Regular auditing of SCIM activity logs for unusual access patterns or attempts to reference resources outside the expected tenant boundary can help in early detection and response to exploitation attempts before significant damage occurs.