Grafana Enterprise sits at the center of many organizations’ observability stacks. It aggregates metrics, logs, traces, and security telemetry from almost everywhere. Because of that, any identity-related flaw in Grafana creates a direct path into a huge amount of sensitive operational data.
CVE-2025-41115 exposes exactly that kind of path. In versions 12.0.0 through 12.2.1, when teams enable SCIM provisioning and configure user synchronization, attackers can abuse the way Grafana maps external SCIM identifiers to internal user IDs. With the right request, a malicious SCIM client can push itself into the identity space of an existing user, including the built-in administrator account.
As a result, this bug earns a CVSS score of 10.0: network exploitable, no prior authentication required, and full impact across confidentiality, integrity, and availability.
𝗪𝗵𝗼 𝗔𝗰𝘁𝘂𝗮𝗹𝗹𝘆 𝗙𝗮𝗰𝗲𝘀 𝗥𝗶𝘀𝗸 𝗙𝗿𝗼𝗺 𝗖𝗩𝗘-𝟮𝟬𝟮𝟱-𝟰𝟭𝟭𝟭𝟱?
Not every Grafana deployment sits in the blast radius. This vulnerability targets a very specific slice of environments:
-
Grafana Enterprise running versions 12.0.0, 12.0.x, 12.1.x, or 12.2.x
-
SCIM provisioning feature turned on
-
User synchronization configured and active for SCIM
In that configuration, Grafana lets SCIM clients create and synchronize users automatically. Many teams enable that setup so they can onboard and offboard users through their identity provider instead of managing accounts manually.
However, once a SCIM client gains that power, any logic error in how Grafana trusts SCIM attributes becomes dangerous. In this case, the danger sits in a single field: externalId.
𝗛𝗼𝘄 𝗧𝗵𝗲 𝗚𝗿𝗮𝗳𝗮𝗻𝗮 𝗦𝗖𝗜𝗠 𝗩𝘂𝗹𝗻𝗲𝗿𝗮𝗯𝗶𝗹𝗶𝘁𝘆 𝗪𝗼𝗿𝗸𝘀
SCIM uses the externalId attribute to carry an identifier from the identity provider into the target system. Grafana Enterprise uses that value when it binds SCIM identities to internal user accounts. Under normal conditions, that mapping simplifies user provisioning and keeps identities consistent.
In vulnerable versions, Grafana maps the SCIM externalId directly to the internal user.uid field. The code path accepts numeric values in externalId and treats them as numeric internal IDs. For example, a SCIM client can send externalId: "1" and Grafana interprets that as “bind this new SCIM user to internal user ID 1.”
Because internal IDs identify real accounts – including the default admin – this behavior opens a privilege-escalation channel. A malicious or compromised SCIM client can:
-
Create a new user with a numeric externalId that matches an existing internal UID
-
Convince Grafana to treat that SCIM user as the existing privileged account
-
Log in through the SCIM-driven identity and operate as an administrator
In other words, the external identity can impersonate the internal identity simply by choosing the right numeric value. The system never enforces a clean separation between external identifiers and internal user IDs.
𝗙𝗿𝗼𝗺 𝗔𝘁𝘁𝗮𝗰𝗸𝗲𝗿’𝘀 𝗣𝗲𝗿𝘀𝗽𝗲𝗰𝘁𝗶𝘃𝗲: 𝗣𝗿𝗶𝘃𝗶𝗹𝗲𝗴𝗲 𝗘𝘀𝗰𝗮𝗹𝗮𝘁𝗶𝗼𝗻 𝗶𝗻 𝗔 𝗙𝗲𝘄 𝗦𝘁𝗲𝗽𝘀
An attacker does not need exotic techniques to abuse this bug. The path looks straightforward:
First, the attacker gains control over a SCIM client or obtains its credentials. That control might come from a compromised identity provider tenant, stolen secrets, misconfigured SCIM connector, or a malicious “integration” that someone installed without proper review.
Next, the attacker sends a provisioning request that creates or updates a user and sets externalId to a numeric value that matches a high-privilege internal user ID. Because Grafana trusts that mapping, it binds the SCIM identity to the privileged account.
Finally, the attacker authenticates through the SCIM-driven identity and uses the Grafana UI or API with full administrator privileges. At that point, they can:
-
View sensitive dashboards and underlying data
-
Change data source configurations
-
Plant or hide alerts
-
Alter permissions and create new users
-
Use the Grafana instance as a pivot point deeper into the environment
The attack path remains simple because the vulnerability sits in identity handling, not in crypto, sandboxing, or some hard-to-reach subsystem.
𝗪𝗵𝘆 𝗦𝗖𝗜𝗠 𝗔𝗻𝗱 𝗢𝗯𝘀𝗲𝗿𝘃𝗮𝗯𝗶𝗹𝗶𝘁𝘆 𝗔𝗿𝗲 𝗦𝘂𝗰𝗵 𝗔 𝗣𝗼𝘄𝗲𝗿𝗳𝘂𝗹 𝗖𝗼𝗺𝗯𝗼 𝗳𝗼𝗿 𝗔𝘁𝘁𝗮𝗰𝗸𝗲𝗿𝘀
SCIM exists to automate identity lifecycle management. It creates accounts, updates attributes, and deprovisions users across many systems. When defenders allow SCIM to provision Grafana identities, they effectively give that automation channel a privileged position inside the observability stack.
Meanwhile, Grafana often holds:
-
Deployment-level metrics about critical services
-
Logs that contain tokens, internal hostnames, and error traces
-
Business dashboards with financial or customer data
-
Security telemetry that blue teams rely on during incident response
If an attacker takes over SCIM provisioning and then takes over Grafana, they gain both visibility and leverage. They can watch the defenders’ dashboards, hide traces of their activity, and pivot to the systems that feed those dashboards with data.
𝗛𝗼𝘄 𝗚𝗿𝗮𝗳𝗮𝗻𝗮 𝗥𝗲𝘀𝗽𝗼𝗻𝗱𝗲𝗱 𝗮𝗻𝗱 𝗪𝗵𝗶𝗰𝗵 𝗩𝗲𝗿𝘀𝗶𝗼𝗻𝘀 𝗙𝗶𝘅 𝗧𝗵𝗲 𝗕𝘂𝗴
Grafana Labs discovered the issue during internal testing, reserved CVE-2025-41115, and rolled out patches across its products. The fix landed in:
-
Grafana Enterprise 12.3.0
-
Grafana Enterprise 12.2.1
-
Grafana Enterprise 12.1.3
-
Grafana Enterprise 12.0.6
Grafana Cloud also received the fix as part of its managed service updates. Open-source Grafana (without SCIM) does not fall into the affected set.
The patches change how Grafana handles SCIM external IDs so that numeric values can no longer override internal UIDs in this way. In other words, the external identity loses its ability to masquerade as an existing internal account just by choosing a number.
𝗜𝗺𝗺𝗲𝗱𝗶𝗮𝘁𝗲 𝗦𝘁𝗲𝗽𝘀 𝗙𝗼𝗿 𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆 𝗧𝗲𝗮𝗺𝘀
Security teams that manage Grafana Enterprise should not treat this as a routine patch. They should assume that attackers will look for unpatched instances and misconfigured SCIM deployments. A practical response plan looks like this:
First, identify every Grafana Enterprise instance in your environment. Include production clusters, internal observability stacks, labs, PoC environments, and any instance that a vendor or MSP manages on your behalf.
Second, check whether SCIM provisioning and user synchronization run on each instance. If both features remain active on a vulnerable version, treat that system as exposed until you patch or disable SCIM.
Third, update to a fixed version as quickly as your change-management process allows. If a delay becomes unavoidable, disable SCIM provisioning and user sync until you complete the upgrade.
Fourth, review logs related to SCIM activity and user creation. Look for:
-
SCIM requests that set numeric externalId values
-
New users that appeared without the usual approval path
-
Changes to high-privilege accounts that came from SCIM operations
Finally, fold Grafana into your broader identity, logging, and response playbooks. Treat it like a Tier-One asset with a formal owner, patch SLOs, and threat-hunting coverage.
𝗟𝗼𝗻𝗴𝗲𝗿-𝗧𝗲𝗿𝗺 𝗟𝗲𝘀𝘀𝗼𝗻𝘀: 𝗜𝗱𝗲𝗻𝘁𝗶𝘁𝘆 𝗔𝘂𝘁𝗼𝗺𝗮𝘁𝗶𝗼𝗻 𝗔𝘀 𝗔𝗻 𝗔𝘁𝘁𝗮𝗰𝗸 𝗦𝘂𝗿𝗳𝗮𝗰𝗲
This incident highlights a bigger pattern. Identity automation and provisioning standards like SCIM sit right next to high-value systems, yet many defenders still treat them like plumbing. When SCIM interacts with observability platforms, security teams need to apply the same skepticism they apply to SSO, VPN gateways, or privileged access tools.
Going forward, teams should:
-
Keep SCIM configurations as simple as possible and avoid unnecessary mappings between external attributes and internal IDs
-
Limit which systems accept SCIM provisioning and ensure that only trusted identity providers can reach those endpoints
-
Perform regular reviews of SCIM clients, credentials, and permissions, just as they do for OAuth and API keys
By doing that, defenders reduce the likelihood that one SCIM misconfiguration turns a monitoring platform into an attacker’s launchpad.
FAQs
Q: Does this issue affect Grafana OSS?
A: No. The vulnerability only applies to Grafana Enterprise versions with SCIM provisioning enabled. Grafana OSS instances without SCIM are not impacted.
Q: What configuration triggers the vulnerability?
A: Both the enableSCIM feature flag and user_sync_enabled=true under [auth.scim] must be configured for the flaw to apply. If either is disabled, the risk is significantly reduced.
Q: What can attackers do if they exploit this flaw?
A: They can impersonate privileged users, modify configurations, manipulate dashboards, hide malicious activity, and access sensitive monitoring data via the compromised Grafana instance.
Q: If we patch now, do we need to assume we were already compromised?
A: Yes. Given the severity and ease of exploitation, teams should perform retrospective forensic reviews of user provisioning logs, administrative actions, and dashboard modifications prior to the patch.
Q: Are managed Grafana cloud instances already safe?
A: According to Grafana Labs, hosted Grafana Cloud environments and managed services like Amazon Managed Grafana and Azure Managed Grafana have been patched. However, you should still verify your specific tenant’s update status.
