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.
