Description

An Editor can set file-provisioning metadata (the grafana.app/managedBy, grafana.app/managerId and grafana.app/sourcePath annotations) when creating a dashboard through the dashboard API, because these fields were stored without an authorization check. The dashboard then appears file-provisioned, and administrators can no longer update or delete it through Grafana. The impact is limited to the same organization and no data is exposed.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.4",
  "pubDate": "2026-09-30T11:16:43.893Z",
  "pubdate": "2026-09-30T11:16:43.893Z",
  "executiveSummary": "This vulnerability involves an improper authorization check within the Grafana dashboard API, allowing users with the 'Editor' role to manipulate file-provisioning metadata. Specifically, by injecting 'grafana.app/managedBy', 'grafana.app/managerId', and 'grafana.app/sourcePath' annotations during dashboard creation, an attacker can designate a dashboard as 'file-provisioned'.\nThis action effectively locks the dashboard, preventing administrators from modifying or deleting it via the Grafana interface, as the system treats these resources as managed by external configuration files. The impact is localized to the specific organization where the dashboard is created. While no sensitive data is directly exposed, this constitutes a denial-of-service condition for administrative resource management. An attacker requires authenticated 'Editor' privileges to perform this injection. The vulnerability highlights a failure in input validation and access control enforcement during the metadata assignment phase of the dashboard lifecycle.",
  "technicalDetails": "The root cause of this vulnerability lies in the insufficient server-side authorization checks performed on dashboard metadata annotations. In Grafana, file-provisioned dashboards are intended to be read-only within the UI to prevent conflicts with external configuration management tools (e.g., provisioning via YAML files). The system identifies these resources using specific annotations: 'grafana.app/managedBy', 'grafana.app/managerId', and 'grafana.app/sourcePath'.\nDuring the dashboard creation process via the API, the application fails to restrict these reserved metadata fields to privileged users or system processes. Consequently, an 'Editor'—a role typically authorized to create and manage dashboards—can supply these keys in the dashboard JSON payload. When the API accepts these fields without validation, the Grafana backend metadata store updates the dashboard object with the provided values.\nThe attack flow proceeds as follows: 1. The attacker authenticates as a user with Editor-level permissions. 2. The attacker initiates a 'POST' request to the dashboard creation endpoint, including the malicious annotations within the dashboard object's metadata section. 3. The API processes the request, storing the metadata without verifying the source or authority of these specific fields. 4. The dashboard is subsequently flagged as 'file-provisioned' by the system.\nOnce this state is achieved, the UI logic restricts any further modifications or deletions by administrative users, as the system presumes the dashboard is managed by an external source. Because administrators are effectively locked out of managing the resource, this creates a localized denial-of-service for that specific dashboard instance. The vulnerability is restricted to the scope of a single organization, as cross-organizational exploitation is not facilitated by this metadata injection. This issue demonstrates a design flaw where internal system state flags are treated as user-controllable metadata, bypassing the intended security boundaries between standard user-created content and system-provisioned infrastructure."
}