Arang

Any authenticated user, including a Viewer, could change the preferences of any team, such as its home dashboard, theme and timezone, through an undocumented endpoint with no access control, and so redirect every member of that team to a dashboard of their choice (missing authorization).

A user with any role, including Viewer or a service account with no permissions, can create, externally publish, and delete dashboard snapshots (missing authorization). Only Grafana OSS and Grafana Enterprise 12.4 are affected; earlier versions and Grafana 13 are not.

Grafana Mimir's Alertmanager rejects tenant-supplied receiver configurations that reference local files, but the check did not cover two HTTP client settings: http headers.<name>.files and basic auth.username file. A tenant permitted to upload an Alertmanager configuration could point these fields at any file readable by the Alertmanager process. When a notification was sent, Alertmanager read the file and put its contents in a header of the outgoing request. By directing the receiver at a server they control, the tenant could read files from the Alertmanager host, such as credentials and configuration. Exploitation requires permission to write the tenant's Alertmanager configuration. Grafana Enterprise Metrics (GEM), which is built on Mimir, is also affected. The issue is fixed in Mimir 3.1.7 and 3.2.2 and in GEM 2.17.20. GEM 2.11 through 2.16 will not receive a fix; users on those versions should upgrade to 2.17.20 or later.

An issue exists where reserved system post types are not validated during the creation and publication of scheduled posts. This allows an authenticated channel member to publish messages that appear as trusted system events through the scheduled post endpoint.

An Editor can set file-provisioning metadata when creating a dashboard through the dashboard API because certain fields are stored without an authorization check. This allows the creation of dashboards that appear as file-provisioned, preventing administrators from updating or deleting them through the interface. The impact is restricted to the same organization, and no data is exposed. The affected metadata includes the `grafana.app/managedBy`, `grafana.app/managerId`, and `grafana.app/sourcePath` annotations.

An issue exists where the system fails to validate whether an assigned incoming webhook user has the necessary access to the target team or channel. This allows a requester with webhook management permissions to create posts or direct messages attributed to another user by using crafted incoming webhook configurations and payloads.