Grafana EUVD-2026-89460

Requires a valid authenticated Grafana account that holds edit permission on at least one folder and only view (not create) permission on the destination folder; the attacker exercises the library elements API or the equivalent App Platform resource update path to change a library panel's parent folder. Limiting factors: exploitation is confined to moving the attacker's own panel and cannot read destination-folder data or modify existing content there, so real-world value is very low; it also depends on a folder-level RBAC configuration where the user's permissions differ across folders (typical only in multi-team Grafana instances using folder permissions).

This is a low-severity authorization flaw whose signals are internally consistent and point to genuinely minor real-world risk. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N = 4.3) shows the only impact is a limited integrity effect (I:L), with no confidentiality or availability impact, and the description reinforces this: no data from the destination folder is disclosed and existing content cannot be changed - the attacker can only relocate their own library panel into a folder where they hold view-only rights. Exploitation requires PR:L (an existing authenticated account with edit permission on at least one folder), so this is not a pre-auth or privilege-escalation-to-admin issue; it is a within-application boundary violation. No EPSS score, KEV listing, or POC was provided in the input, so exploitation status is: no public exploit identified at time of analysis. There is no conflict among the available signals - low CVSS, narrow impact, and required privileges all agree this is a housekeeping-grade authorization bug, not an urgent priority. The main caveat is that no EPSS/SSVC data was supplied to quantify exploitation likelihood, but given the trivial impact this does not change the assessment.

An authenticated Grafana user who has edit permission on Folder A but only view permission on Folder B uses the library elements API (or the equivalent App Platform resource) to update a library panel's folder, moving it from A into B. Because the update path fails to check library-panel create permission on the destination, the panel lands in B despite the user lacking create rights there. No POC was provided, and the impact is limited to placing the user's own panel where they normally could not create content.