CVE-2026-40179

What it actually does

This is a stored cross-site scripting flaw in the Prometheus 3.x web UI. Prometheus versions 3.0 through 3.5.1 and 3.6.0 through 3.11.1 can render attacker-controlled metric names or label values as HTML/JavaScript instead of text in multiple UI locations, including Graph page chart tooltips, old React UI Metric Explorer fuzzy search results, and heatmap cell tooltips. Because Prometheus 3.x allows UTF-8 metric and label names by default, characters such as <, >, and quotes can be ingested into time-series metadata. If an attacker can cause malicious metrics or labels to be scraped, remote-written, or received through OTLP, JavaScript can execute in the browser of a Prometheus user who views affected UI elements. The script runs in the Prometheus web origin and may be able to read visible UI data, make same-origin API requests, exfiltrate configuration or query results, and trigger mutating actions such as deletion, shutdown, or reload when dangerous web flags such as --web.enable-admin-api or --web.enable-lifecycle are enabled.

Why it matters to the business

A compromised scrape target, exposed metrics ingestion endpoint, or malicious telemetry source could turn the monitoring console into a delivery mechanism for browser-based compromise. Successful exploitation can expose monitoring data, configuration details, service topology, labels containing operational metadata, and potentially enable disruptive administrative actions if mutating Prometheus APIs are enabled. The CVSS score is moderate and EPSS is currently low at 0.00259 with no 30-day increase, and it is not known to be in CISA KEV or ransomware campaigns; however, Prometheus is commonly deployed in production observability stacks, so the operational blast radius can be meaningful where untrusted telemetry is ingested or the UI is used by privileged operators.

How an attack unfolds

An attacker first obtains a way to introduce metric names or label values into Prometheus. Common paths include compromising a scrape target, standing up a malicious scrape endpoint that Prometheus is configured to collect from, abusing an exposed remote write receiver, or sending crafted telemetry to an exposed OTLP receiver. The attacker embeds HTML or JavaScript payloads in metric names or label values, taking advantage of Prometheus 3.x UTF-8 metric and label validation. Prometheus stores the poisoned series. Later, a user opens the Prometheus web UI and views the affected metric on the Graph page, uses the old React Metric Explorer fuzzy search, or views affected heatmap tooltips. The UI inserts the attacker-controlled value into innerHTML or dangerouslySetInnerHTML without escaping, causing the browser to execute the payload. The payload then acts with the user’s browser session and Prometheus origin privileges, such as reading displayed data, issuing Prometheus API requests, exfiltrating results, or invoking lifecycle/admin endpoints if they are enabled and reachable.

How to fix it

Upgrade Prometheus to a fixed release: 3.5.2 for the 3.5 line or 3.11.2 or later for the 3.11 line. Treat all Prometheus versions 3.0 through 3.5.1 and 3.6.0 through 3.11.1 as affected. If an immediate upgrade is not possible, reduce exploitability by ensuring --web.enable-remote-write-receiver and --web.enable-otlp-receiver are not exposed to untrusted sources, allowing ingestion only from trusted scrape targets and telemetry producers, and placing receiver endpoints behind authentication, authorization, and network controls. Avoid enabling mutating or administrative web flags such as --web.enable-admin-api and --web.enable-lifecycle where untrusted data may be ingested. Restrict access to the Prometheus web UI to trusted users over authenticated paths. Avoid clicking untrusted Prometheus graph links, especially links using functions such as label_replace that may generate attacker-controlled label names or values.

How to confirm the fix worked

Confirm the running Prometheus version with prometheus --version, package metadata, container image tags, or the Prometheus /status page where available. The deployment should report 3.5.2, 3.11.2, or a later non-vulnerable version. Review runtime flags and configuration to verify that exposed ingestion and mutating endpoints are disabled or restricted, specifically --web.enable-remote-write-receiver, --web.enable-otlp-receiver, --web.enable-admin-api, and --web.enable-lifecycle. Validate network controls by confirming that remote write and OTLP receiver endpoints are not reachable from untrusted networks. In a non-production test environment, ingest a harmless metric or label containing HTML-like characters such as <b>test</b> and verify that the Graph UI and tooltips render it as text rather than executing or interpreting markup. Query stored metric names and label values for suspicious HTML/JavaScript patterns to confirm existing telemetry does not contain poisoned series.

Typical attack path

1. Identify or gain control of a telemetry source that Prometheus ingests, such as a scrape target, remote write client, or OTLP sender.
2. Craft a metric name or label value containing HTML/JavaScript payload characters such as <, >, quotes, event handlers, or script-like markup.
3. Cause Prometheus to ingest and store the poisoned time series.
4. Wait for or lure a Prometheus user to open the Graph UI, Metric Explorer, or affected heatmap/tooltip view that renders the poisoned value.
5. The vulnerable UI renders the malicious metric or label as HTML instead of escaped text, executing JavaScript in the user’s browser.
6. Use the browser context to read Prometheus data, call same-origin APIs, exfiltrate information, or perform mutating actions if admin/lifecycle APIs are enabled.

How to detect it

To determine whether exploitation may already have occurred, correlate telemetry ingestion, suspicious metric metadata, and Prometheus UI/API activity. First, inspect Prometheus metric names and label values for HTML or JavaScript-like content, especially payloads containing script tags, image/svg tags, event-handler attributes, javascript: URLs, encoded angle brackets, or label_replace-generated suspicious labels. Use Prometheus APIs such as /api/v1/label/__name__/values and targeted label-value queries where practical, and consider TSDB inspection or offline block analysis for historical data. Next, review reverse proxy, load balancer, ingress, and Prometheus web access logs for writes to /api/v1/write or OTLP receiver paths from unusual sources, followed by user visits to /graph or query URLs referencing the poisoned metric. Look for Prometheus API calls made from browser sessions shortly after UI views, particularly calls to delete-series, clean tombstones, snapshot, config, flags, reload, or quit endpoints if admin or lifecycle APIs were enabled. Investigate scrape targets or telemetry senders that first introduced suspicious metric names or label values. Browser-side evidence may be limited, but enterprise proxy, EDR, or DNS logs may show exfiltration attempts from operator workstations immediately after Prometheus UI access. There are no public KEV or named threat actor indicators supplied for this issue, so detection should focus on malicious metric content and suspicious Prometheus-origin API activity rather than actor-specific infrastructure.

• <script
• </script>
• %3Cscript
• %3C%2Fscript%3E
• javascript:
• onerror=
• onload=
• <img
• <svg
• dangerouslySetInnerHTML
• label_replace
• /api/v1/write
• /api/v1/otlp/v1/metrics
• /graph
• /api/v1/admin/tsdb/delete_series
• /api/v1/admin/tsdb/clean_tombstones
• /-/reload
• /-/quit
• --web.enable-remote-write-receiver
• --web.enable-otlp-receiver
• --web.enable-admin-api
• --web.enable-lifecycle

What your security team should do

• Prioritize upgrading affected Prometheus 3.x deployments to 3.5.2, 3.11.2, or later, especially instances that ingest telemetry from many teams, dynamic workloads, third-party exporters, or externally reachable receivers.
• Immediately disable or restrict --web.enable-remote-write-receiver and --web.enable-otlp-receiver unless they are required and protected by strong network and identity controls.
• Disable --web.enable-admin-api and --web.enable-lifecycle unless explicitly required; these flags increase the impact of browser-origin API abuse after XSS.
• Restrict Prometheus web UI access to trusted operators and authenticated administrative networks.
• Search stored metric names and label values for HTML/JavaScript patterns and investigate any poisoned series back to the scrape target, remote write client, or OTLP source.
• Review reverse proxy, load balancer, and Prometheus access logs for suspicious UI visits or API calls following ingestion of malicious-looking metric metadata.
• Educate operators not to open untrusted Prometheus graph links or query URLs until affected deployments are upgraded.