New MCP server — Bring vulnerability intelligence into your AI
Back to feed

CVE-2021-41174

ExploitedNVDCIRCLENISA

EUVD-2021-2285 · Published Nov 8, 2021

XSS vulnerability allowing arbitrary JavaScript execution

Today we are releasing Grafana 8.2.3. This patch release includes an important security fix for an issue that affects all Grafana versions from 8.0.0-beta1.

Grafana Cloud instances have already been patched and an audit did not find any usage of this attack vector. Grafana Enterprise customers were provided with updated binaries under embargo.

CVE-2021-41174 XSS vulnerability on unauthenticated pages

Summary

CVSS Score: 6.9 Medium
CVSS:CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:C/C:L/I:H/A:N/E:U/RL:O/RC:R/CR:L/MAV:N/MAC:H/MPR:N/MUI:R/MS:C/MC:N/MI:H/MA:L

We received a security report to security@grafana.com on 2021-10-21 about a vulnerability in Grafana regarding the XSS vulnerability.

It was later identified as affecting Grafana versions from 8.0.0-beta1 to 8.2.2. CVE-2021-41174 has been assigned to this vulnerability.

Impact

If an attacker is able to convince a victim to visit a URL referencing a vulnerable page, arbitrary JavaScript content may be executed within the context of the victim's browser.

The user visiting the malicious link must be unauthenticated and the link must be for a page that contains the login button in the menu bar.

There are two ways an unauthenticated user can open a page in Grafana that contains the login button:

  • Anonymous authentication is enabled. This means all pages in Grafana would be open for the attack.
  • The link is to an unauthenticated page. The following pages are vulnerable:
    • /dashboard-solo/snapshot/*
    • /dashboard/snapshot/*
    • /invite/:code

The url has to be crafted to exploit AngularJS rendering and contain the interpolation binding for AngularJS expressions. AngularJS uses double curly braces for interpolation binding: {{ }}

An example of an expression would be: {{constructor.constructor(‘alert(1)’)()}}. This can be included in the link URL like this:

https://play.grafana.org/dashboard/snapshot/{{constructor.constructor('alert(1)')()%7D%7D?orgId=1

When the user follows the link and the page renders, the login button will contain the original link with a query parameter to force a redirect to the login page. The URL is not validated and the AngularJS rendering engine will execute the JavaScript expression contained in the URL.

Attack audit

We can not guarantee that the below will identify all attacks, so if you find something using the audit process described below, you should consider doing a full assessment.

Through reverse proxy/load balancer logs

To determine if your Grafana installation has been exploited for this vulnerability, search through your reverse proxy/load balancer access logs for instances where the path contains {{ followed by something that would invoke JavaScript code. For example, this could be code that attempts to show a fake login page or to steal browser or session data. The OWASP cheat sheet has several examples of XSS attacks.

Through the Grafana Enterprise audit feature

If you enabled “Log web requests” in your configuration with router_logging = true, look for requests where path contains {{ followed by something that would invoke JavaScript code.

Patched versions

Release 8.2.3:

Solutions and mitigations

Download and install the appropriate patch for your version of Grafana.

Grafana Cloud instances have already been patched, and Grafana Enterprise customers were provided with updated binaries under embargo.

Workaround

If for some reason you cannot upgrade, you can use a reverse proxy or similar to block access to block the literal string {{ in the path.

Example of an Nginx rule to block the literal string {{:

location ~ \{\{ {
    deny all;
}
Timeline and postmortem

Here is a detailed timeline starting from when we originally learned of the issue. All times in UTC.

  • 2021-10-21 23:13: Security researcher sends the initial report about an XSS vulnerability.
  • 2021-10-21 23:13: Confirmed to be reproducible in at least versions 8.0.5 and 8.2.2.
  • 2021-10-22 02:02 MEDIUM severity declared.
  • 2021-10-22 09:22: it is discovered that Grafana instances with anonymous auth turned on are vulnerable. This includes https://play.grafana.org/ .
  • 2021-10-22 09:50: Anonymous access disabled for all instances on Grafana Cloud as a mitigation measure.
  • 2021-10-22 11:15: Workaround deployed on Grafana Cloud that blocks malicious requests.
  • 2021-10-22 12:35: Enabled anonymous access for instances on Grafana Cloud.
  • 2021-10-22 12:51: All instances protected by the workaround. From this point forward, Grafana Cloud is no longer affected.
  • 2021-10-22 14:05 Grafana Cloud instances updated with a fix.
  • 2021-10-22 19:23 :Determination that no weekend work is needed as the issue is of MEDIUM severity and the root cause has been identified.
  • 2021-10-25 14:13: Audit of Grafana Cloud concluded, no evidence of exploitation.
  • 2021-10-27 12:00: Grafana Enterprise images released to customers under embargo.
  • 2021-11-03 12:00: Public release.

Reporting security issues

If you think you have found a security vulnerability, please send a report to security@grafana.com. This address can be used for all of
Grafana Labs' open source and commercial products (including but not limited to Grafana, Tempo, Loki, k6, Tanka, and Grafana Cloud, Grafana Enterprise, and grafana.com). We only accept vulnerability reports at this address. We would prefer that you encrypt your message to us using our PGP key. The key fingerprint is:

F988 7BEA 027A 049F AE8E 5CAA D125 8932 BE24 C5CA

The key is available from keyserver.ubuntu.com by searching for security@grafana.

Security announcements

There is a Security category on the Grafana blog where we will post a summary, remediation, and mitigation details for any patch containing security fixes and you can subscribe to updates from our Security Announcements RSS feed.

Technologies

Grafana GrafanaGrafana Data

Weaknesses

CWE-79

CVSS scores

  • v3.16.9CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:L/I:H/A:N

MITRE ATT&CK

Inferred

Where this vulnerability fits in an attack

Initial Access

References

Potentially impacted assets

See if this affects your attack surface

Latest trending attack

Criticalyesterday

Google Brotli decoder - Remote Code Execution via compressed requests (Exploitation Check)

This control is the second step of the Patrowl response to CVE-2026-111497 (Node2Shell). It complements the first control of 22 October 2026, which focused on the Node.js runtime, and does not replace it. Why a second control CVE-2026-111497 is an out-of-bounds write in the Google Brotli decoder, the library that decompresses Brotli ("br") data. It was first published as a Node.js vulnerability, because Node.js bundles this decoder. Later publications showed that the flaw is in the library itself. Every product that embeds an affected version of the decoder is concerned, whatever its language or vendor. A public proof of concept demonstrates code execution. Any server that decompresses request bodies sent with "Content-Encoding: br" exposes the decoder to unauthenticated attackers. Known cases include Express 5 and NestJS 11 on Node.js, Koa and Fastify setups, Bun, Envoy and Istio with request decompression enabled, and any application or reverse proxy that decodes Brotli request bodies with an affected library. The flaw also works in the other direction. A malicious server can compromise an unpatched client that decodes a Brotli response, for example Node.js fetch(), Python clients (requests, httpx, aiohttp, Scrapy) with the Brotli or brotlicffi package, or libcurl builds with Brotli support. What this control checks Patrowl sends small, valid Brotli-compressed requests to each asset and observes whether the server decodes them. The check does not depend on the technology: it detects the behaviour, whatever the stack behind it. These requests are what any legitimate client could send. They never reach the vulnerable code path and cannot affect the availability of the service. How to read the result Potentially impacted means the asset decodes Brotli request bodies: the attack surface is exposed. It does not confirm that the asset is vulnerable. The version of the Brotli decoder in use is not visible from the outside. This check covers applications that parse request bodies on their root path. A Not impacted result does not rule out exposure on other routes, nor on the client side. Checking the versions on the servers remains the only exhaustive verification. Affected and fixed versions Google Brotli 1.0.3 to 1.2.0 are affected, fixed in 1.0.10, 1.1.1 and 1.2.1. Fixed releases of the main products embedding it: Node.js 22.23.4, 24.22.1 and 26.12.1 (end-of-life lines 20.x and older and 25.x receive no fix), Bun 1.4.4, Envoy 1.37.8, 1.38.6, 1.39.3 and 1.40.0, Istio 1.29.9, 1.30.6 and 1.31.2, Python Brotli 1.2.1 and brotlicffi 1.2.1.0. Products that link against the system library depend on the Brotli package of the Linux distribution. Recommendations Update every component that embeds the Brotli decoder (only real fix). Start with the assets flagged by this control. Restart the processes after the update. Rebuild containers, single-executable applications and appliances that bundle an affected runtime or library. Reduce the exposure until the update is deployed. Reject requests with "Content-Encoding: br" at the reverse proxy, load balancer or WAF, case-insensitively and including lists such as "gzip, br". On Envoy and Istio, disable request decompression for Brotli. Review outbound calls. List the features that fetch content from servers you do not control, and patch the services that host them first.

Take 15 minutes to discover our platform with our experts

Patrowl Intel platform screenshot