CVE-2025-4123

What it actually does

The vulnerability allows a network attacker to combine client-side path traversal with an open redirect in Grafana to cause a victim’s browser to load attacker-controlled frontend plugin content and execute arbitrary JavaScript in the Grafana web context. Exploitation requires user interaction, but does not require attacker authentication or editor permissions; if anonymous access is enabled, the attack can execute against unauthenticated sessions. Successful XSS can read sensitive dashboard data accessible to the victim, perform actions as the victim, modify limited UI-visible state, and potentially disrupt availability. Grafana’s default Content-Security-Policy can block the JavaScript execution through the connect-src directive, but weakened or customized CSP configurations increase risk. If the Grafana Image Renderer plugin is installed, the same open redirect behavior may be abused to perform full read server-side request forgery, allowing the renderer to fetch internal or otherwise restricted URLs.

Why it matters to the business

A successful attack can expose dashboards, queries, metrics, logs, tokens, and operational data visible to targeted users, and can let attackers perform actions through trusted user sessions. Organizations using Grafana for production monitoring may face leakage of infrastructure details, service health information, incident data, and credentials embedded in dashboards or data-source responses. The very high EPSS score and weaponized exploit maturity indicate a high likelihood of real-world exploitation despite the absence of CISA KEV listing. Environments with anonymous Grafana access, customized permissive CSP, internet-facing instances, or the Grafana Image Renderer plugin have materially higher operational risk.

How an attack unfolds

An attacker first identifies an exposed Grafana instance and determines whether anonymous access, permissive CSP settings, or the Image Renderer plugin are present. The attacker crafts a URL that abuses client-side path traversal and an open redirect so that Grafana navigation causes the victim browser to reach an attacker-controlled location hosting malicious frontend plugin content. The attacker then delivers the URL through phishing, chat, ticket comments, embedded links, or another channel likely to be opened by a Grafana user. When the victim opens the link, malicious JavaScript may execute in the Grafana security context if CSP does not block it. The script can read data available to the user, call Grafana APIs as that user, alter dashboards or settings within the user’s permissions, and exfiltrate information to attacker infrastructure. If the Image Renderer plugin is installed, the attacker may also exploit the redirect behavior through rendering workflows to make the renderer fetch arbitrary URLs, including internal network resources, turning the issue into a read-oriented SSRF path.

How to fix it

Upgrade Grafana to a fixed build or release containing commit a33fc073bf8b395da943a32c08a1217f7a7a30e0. For source-based deployments, verify the deployed tree includes this commit. For packaged deployments, install the vendor release that includes this fix rather than relying on compensating controls alone. Preserve or restore Grafana’s restrictive default Content-Security-Policy, especially connect-src and related directives, and avoid wildcard or overly broad external origins. Disable anonymous access unless explicitly required. Remove or disable the Grafana Image Renderer plugin if it is not needed, and restrict renderer network egress to only approved destinations. Place Grafana behind authentication and a reverse proxy where possible, block encoded path traversal patterns, and monitor or deny redirects to untrusted external domains. Rotate exposed credentials or API tokens if exploitation is suspected.

How to confirm the fix worked

Confirm the running Grafana build includes fixed commit a33fc073bf8b395da943a32c08a1217f7a7a30e0 or a vendor release documented as containing the fix. Validate that anonymous access is disabled unless intentionally required. Review the effective CSP headers returned by Grafana and confirm connect-src does not allow arbitrary external destinations. From a test client, attempt a benign reproduction using encoded path traversal and an external redirect target; a fixed or properly mitigated system should not allow attacker-controlled plugin content to execute in the Grafana origin. If Image Renderer is installed, verify renderer egress controls prevent access to internal metadata services, loopback addresses, RFC1918 networks, and other sensitive internal endpoints. Review reverse proxy and Grafana logs after testing to confirm blocked traversal/redirect attempts are visible to monitoring.

Typical attack path

1. Find an internet-accessible or user-accessible Grafana instance.
2. Check whether anonymous access, permissive CSP, external plugin loading behavior, or the Grafana Image Renderer plugin are present.
3. Craft a URL that combines client-side path traversal with an open redirect to attacker-hosted plugin or script content.
4. Send the crafted URL to a target user or place it where Grafana users are likely to click it.
5. Victim opens the URL and the browser follows the redirect/path traversal chain.
6. Attacker-controlled frontend content executes in the Grafana web context if not blocked by CSP.
7. Malicious script reads accessible dashboards, data-source responses, user/session context, or Grafana API data.
8. Attacker exfiltrates collected data or performs actions using the victim’s Grafana permissions.
9. If Image Renderer is installed, attacker abuses redirect behavior to cause server-side rendering components to fetch internal URLs for read SSRF.

How to detect it

Look for evidence in reverse proxy logs, Grafana server logs, access logs, browser security telemetry, CSP violation reports, DNS logs, outbound proxy logs, and Grafana Image Renderer logs. Focus on requests to Grafana paths that include plugin resources combined with ../ traversal, URL-encoded traversal such as %2e%2e%2f, double-encoded traversal, or absolute external URLs embedded in paths or redirect parameters. Investigate HTTP 3xx responses from Grafana that send users to unfamiliar external domains, followed by requests for JavaScript or plugin assets from those domains. CSP reports are especially useful: blocked connect-src or script-related violations shortly after Grafana navigation may indicate attempted exploitation that was stopped by policy. For suspected SSRF through Image Renderer, review renderer logs and network telemetry for requests from renderer hosts to loopback, link-local, cloud metadata, RFC1918, or otherwise internal-only addresses. Correlate suspicious link clicks with subsequent Grafana API activity by the same user, including dashboard reads, data-source queries, snapshot creation, API key or service account activity, user/admin changes, and unusual exports. Because exploit maturity is weaponized and EPSS is very high, treat matching patterns as high-priority even without successful JavaScript execution evidence.

• /public/plugins/
• ../
• ..%2f
• %2e%2e%2f
• %252e%252e%252f
• ..%5c
• %2e%2e%5c
• %252e%252e%255c
• %2f..%2f
• %5c..%5c
• /render/
• render/d-solo
• render/dashboard
• connect-src
• Content Security Policy
• violated-directive: connect-src
• violated-directive=connect-src
• blocked-uri: http
• blocked-uri: https
• 169.254.169.254
• metadata.google.internal
• metadata/instance
• latest/meta-data
• 127.0.0.1
• localhost
• ::1

What your security team should do

• Prioritize patching internet-facing Grafana instances and any instance with anonymous access, permissive CSP, or the Image Renderer plugin.
• Upgrade to a release containing fixed commit a33fc073bf8b395da943a32c08a1217f7a7a30e0 and verify the fix in production.
• Immediately review CSP configuration and remove wildcard or unnecessary external origins from connect-src and related directives.
• Disable anonymous access unless there is a documented business requirement and compensating controls are in place.
• Disable or tightly restrict Grafana Image Renderer, including outbound network access from renderer components.
• Search access logs, proxy logs, CSP reports, DNS logs, and egress proxy logs for exploitation patterns involving encoded traversal, external redirects, and unusual plugin asset loads.
• Investigate any suspicious Grafana sessions following crafted-link access, including dashboard exports, API calls, data-source queries, user changes, and token activity.
• Rotate Grafana API keys, service account tokens, and credentials stored in or exposed through dashboards if exploitation is plausible.
• Add WAF or reverse-proxy rules to alert on or block requests containing encoded traversal sequences and suspicious external redirect targets involving Grafana plugin paths.