Grafana Alerting : ce que corrige et ce qu’apporte Grafana 13.2.0

Grafana 13.2.0 est sortie le 18 août 2026 à 12:48 UTC, publiée depuis le dépôt GitHub officiel du projet sous le commit f681b13, signature vérifiée, et marquée comme dernière version. Elle contient deux choses à la fois : un défaut d’autorisation de sévérité haute dans l’alerting unifié, qui a reçu son propre avis de sécurité le lendemain, et un lot de nouveautés qui n’a rien à voir avec la sécurité. Les deux comptent, mais pas pour tout le monde de la même façon.

Ce que permet réellement CVE-2026-17183

L’avis GHSA-f74r-h7qj-c63f a été publié au NVD et à la GitHub Advisory Database le 19 août 2026. Sévérité High, score CVSS 3.1 de 7.1, vecteur CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N, catégorie CWE-863 (autorisation incorrecte). Le composant touché est Grafana Alerting, l’alerting unifié (ngalert) de Grafana OSS. La reproduction a été confirmée sur la 13.0.1, et la plage de versions affectées est officiellement « non encore évaluée » : il n’y a donc pas encore d’intervalle officiel à citer.

Le bug tient à une erreur de classification. Un utilisateur authentifié, peu privilégié, membre de la même organisation Grafana et autorisé à créer ou modifier des règles d’alerte dans un dossier auquel il a accès, envoie une requête de règle d’alerte avec le champ queryType positionné à __expr__, tout en gardant dans datasourceUid l’UID d’une vraie source de données. La couche d’autorisation lit queryType, en déduit qu’il s’agit d’une expression côté serveur, et saute la vérification de la permission datasources:query. L’évaluateur, lui, lit DatasourceUID, résout la vraie source de données et exécute la requête contre elle.

L’autorisation fait confiance à un champ, l’exécution à un autre. L’impact sur la confidentialité est High : tout ce que les identifiants de la source de données configurée dans Grafana peuvent lire, l’attaquant peut le lire. L’intégrité est notée Low, parce que certains backends acceptent des requêtes qui modifient l’état. Aucun impact sur la disponibilité n’a été démontré, et aucune interaction utilisateur n’est nécessaire. La faille a été trouvée par le chercheur czarflix via le programme Intigriti de Grafana Labs, sous le rapport GRAFANALABS-F996ATD7.

Faut-il mettre à jour ce soir ?

Probablement pas, et ce sont les prérequis qui l’expliquent. Il faut un compte authentifié dans votre organisation, le droit de créer ou modifier des règles d’alerte dans au moins un dossier, et l’UID de la source de données visée. Cela fait beaucoup de conditions à réunir.

Si votre instance Grafana est derrière un reverse proxy et que votre compte est le seul à y exister, ce qui décrit une bonne partie des homelabs, personne n’est en position d’exploiter quoi que ce soit. Mettez à jour quand vous le faites d’habitude.

Une instance partagée, c’est une autre discussion. Si vous avez donné des accès à des proches ou à une petite équipe, si l’auto-inscription est active, ou s’il traîne de vieux comptes Editor, alors toute personne capable de toucher aux règles d’alerte peut lire des sources que vous ne lui avez jamais ouvertes. Y compris ce à quoi vos sources Prometheus ou SQL sont raccordées. Aucune exploitation publique n’a été signalée, mais dans cette configuration l’exposition est réelle.

Un récapitulatif publié par Elestio le 23 août indique que le correctif a aussi été rétroporté en 13.1.4, 13.0.7, 12.4.9 et 12.3.11, la veille de la sortie de 13.2.0. C’est une source secondaire, mais si l’information se confirme, vous pouvez prendre le correctif sur votre branche actuelle sans changer de version mineure.

Le reste de la version

C’est Grafana Alerting qui a reçu le plus d’attention. Un nouvel onglet Import apparaît dans les paramètres d’alerting, l’assistant import-to-GMA sait maintenant récupérer les modèles de notification, et une configuration importée en attente peut être annulée au lieu d’être définitive. L’API notifications passe en v1beta1, et les conflits de provenance sur les points de contact renvoient un 403 plutôt qu’un 500.

Git Sync est l’autre chantier réel, et la partie à lire avant de mettre à jour si vous provisionnez depuis un dépôt. Les webhooks et l’attribution utilisateur sont activés par défaut, les jobs sont rattachés à leur auteur et à leur origine, et les webhooks GitLab et Bitbucket arrivent, certains éléments restant réservés à l’édition Enterprise.

Le reste :

• Les dashboards s’imbriquent maintenant sur quatre niveaux, avec des onglets imbriqués. Les erreurs et messages de requête d’un panneau sont regroupés dans une seule interface.
• Les dashboards scriptés sont dépréciés et désactivés par défaut. À vérifier avant la mise à jour si vous en utilisez encore.
• La page d’accueil unifiée est activée pour tous les utilisateurs, et son feature flag disparaît.
• Grafana Live accepte les URL redis:// et rediss:// dans ha_engine_address.
• Un seul changement cassant est listé, côté alerting : le feature flag alertingSaveStateCompressed a été supprimé.

Les corrections côté auto-hébergement sont de celles qu’on ne remarque que le jour où elles vous tombent dessus. La source PostgreSQL ne refuse plus de démarrer quand maxOpenConns=0, et les chaînes epoch en millisecondes ne se transforment plus en NaN. SQLite retrouve son journal mode quand WAL est désactivé. Go passe en 1.26.5.

Mettre à jour une installation Docker

Rien d’exotique avec l’image officielle : pull, recréation du conteneur, terminé. Sauvegardez d’abord votre base, comme toujours. Les deux points qui méritent une lecture des notes de version sont les valeurs par défaut de Git Sync et la dépréciation des dashboards scriptés, deux changements de comportement qui s’appliquent sans qu’on les demande. Pour la plupart des homelabs mono-utilisateur, la CVE est la moitié la moins urgente de cette version.

Sources : les notes de version officielles v13.2.0 sur GitHub et l’avis de sécurité Grafana pour CVE-2026-17183.