Post cover image

November 1, 2026

Grafana SSO settings authorization bypass, CVE-2026-103506 (CVSS 4.0 8.9)

A missing permission check in Grafana 13.2 lets signed-in users read SSO client secrets and change login settings.

By Karan Shah

3 min read

CVE-2026-103506 lets any signed-in Grafana user read single sign-on client secrets and rewrite the login settings for the whole instance, without holding the permissions those actions require. Grafana Labs scored it 8.9 under CVSS version 4.0, and NVD had not added its own score when this was written. The NVD entry does not list the flaw as exploited in real attacks.

What the SSO settings API controls

Single sign-on, or SSO, lets people log in to Grafana with an account from an outside identity provider that speaks OAuth2 or SAML. Grafana's SSO settings API stores that connection: which provider to trust, the client ID, and the client secret Grafana uses to prove its own identity to the provider.

Grafana's documentation ties each operation to a permission:

  • Listing or reading provider settings needs the settings:read action.
  • Replacing or deleting them needs settings:write.

Values saved through this API override the configuration file, so a change made there applies to the whole server.

The check that should happen

Every request to these endpoints should answer two questions. Is the caller logged in? Does that account hold settings:read or settings:write for the provider it is touching?

The second question is authorization. Authentication only confirms who a user is, while authorization decides what that known user may do. CWE-285, the weakness listed for this CVE, covers the case where the second step is missing or wrong.

The check that is missing

Grafana 13.2 ships an experimental feature toggle named kubernetesSsoSettingsApi. A feature toggle is a switch that turns on code still under development. With this switch on, Grafana confirms the caller has a valid login but does not confirm the caller holds the settings permissions.

What that allows, for an account with low privileges as the CVSS vector records:

  1. The user sends a request for the stored SSO settings.
  2. Grafana accepts the session and returns the settings, client secrets included.
  3. The same user sends new values, and Grafana saves them as the instance-wide SSO configuration.
Diagram: a low-privilege user passes the login check, the permission check is skipped, secrets are returned and new SSO settings saved

Why the exposed settings matter

A client secret acts as a password for the Grafana application itself at the identity provider. Anyone holding it can present requests to that provider as if they came from Grafana.

Write access covers the same settings that decide which provider Grafana trusts for logins, so a change affects every person who signs in through SSO. The CVSS vector rates the impact on connected systems as high, in addition to the impact on Grafana itself.

Which Grafana servers are at risk

Grafana's security advisory lists these conditions:

  • Grafana OSS or Grafana Enterprise, versions 13.2.0 through 13.2.4.
  • The kubernetesSsoSettingsApi toggle is enabled. It is off by default.
  • Releases before 13.2.0, and 13.2.5 or later, are listed as not affected.

Steps for site owners:

  • Check the Grafana version on every server.
  • Check whether kubernetesSsoSettingsApi appears among the enabled feature toggles.
  • Upgrade affected servers to 13.2.5 or later.
  • Where the toggle was on, issue a new client secret at the identity provider and review the SSO settings for changes nobody approved.

Turning the toggle off removes the affected setup until an upgrade is possible, since Grafana says only installations with it enabled are exposed. The flaw was reported by a researcher Grafana credits as kazuki-hanai through its disclosure program.

How the fix approach matches authorization guidance

Grafana describes the root cause as missing authorization, and 13.2.5 is the release that closes it. OWASP's Authorization Cheat Sheet recommends validating permissions on every request through a shared mechanism such as middleware, denying access by default, and writing tests that confirm a low-privilege account is refused. Under that approach, a new way of reaching existing settings inherits the same settings:read and settings:write checks instead of depending on each new route to add its own.

Sources

Official