Vulnerability-Lookup

Vulnerability from cleanstart

Published

2026-07-30 07:10

Modified

2026-07-30 09:32

Summary

Security fixes in tempo-fips 2.7.2-r0

Details

Package tempo-fips version 2.7.2-r0 fixes 35 vulnerabilities: CVE-2026-33186, CVE-2025-22869, CVE-2025-47914, CVE-2025-58181, CVE-2025-47913...

References

URL

Type

https://github.com/grafana/tempo

WEB

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Alpine",
        "name": "tempo-fips"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.7.2-r0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "2.7.2-r0"
      ]
    }
  ],
  "credits": [],
  "database_specific": {},
  "details": "Package tempo-fips version 2.7.2-r0 fixes 35 vulnerabilities: CVE-2026-33186, CVE-2025-22869, CVE-2025-47914, CVE-2025-58181, CVE-2025-47913...",
  "id": "CLEANSTART-2026-GG76815",
  "modified": "2026-07-30T09:32:26Z",
  "published": "2026-07-30T07:10:53Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/grafana/tempo"
    }
  ],
  "related": [],
  "schema_version": "1.7.3",
  "summary": "Security fixes in tempo-fips 2.7.2-r0",
  "upstream": [
    "CVE-2026-33186",
    "CVE-2025-22869",
    "CVE-2025-47914",
    "CVE-2025-58181",
    "CVE-2025-47913",
    "CVE-2025-22868",
    "CVE-2025-22870",
    "CVE-2025-22872",
    "CVE-2025-29786",
    "CVE-2025-68156",
    "CVE-2025-30204",
    "CVE-2026-32287",
    "CVE-2025-11065",
    "CVE-2026-40179",
    "CVE-2026-32280",
    "CVE-2026-32281",
    "CVE-2026-32282",
    "CVE-2026-32283",
    "CVE-2026-32288",
    "CVE-2026-32289",
    "CVE-2026-33810",
    "ghsa-p77j-4mvh-x3m3",
    "ghsa-hcg3-q754-cr77",
    "ghsa-6v2p-p543-phr9",
    "ghsa-mh63-6h87-95cp",
    "ghsa-93mq-9ffx-83m2",
    "ghsa-cfpf-hrx2-8rv6",
    "ghsa-65xw-vw82-r86x",
    "ghsa-vvgc-356p-c3xw",
    "ghsa-qxp5-gwg8-xv66",
    "ghsa-2464-8j7c-4cjm",
    "ghsa-fv92-fjc5-jj9h",
    "ghsa-vffh-x6r8-xx99",
    "ghsa-j5w8-q4qc-rx2x",
    "ghsa-f6x5-jh6r-wrfv"
  ]
}

GHSA-MH63-6H87-95CP

Vulnerability from github – Published: 2025-03-21 22:04 – Updated: 2025-04-10 13:02

Summary

jwt-go allows excessive memory allocation during header parsing

Details

Summary

Function parse.ParseUnverified currently splits (via a call to strings.Split) its argument (which is untrusted data) on periods.

As a result, in the face of a malicious request whose Authorization header consists of Bearer followed by many period characters, a call to that function incurs allocations to the tune of O(n) bytes (where n stands for the length of the function's argument), with a constant factor of about 16. Relevant weakness: CWE-405: Asymmetric Resource Consumption (Amplification)

Details

See parse.ParseUnverified

Impact

Excessive memory allocation

Severity

7.5 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

8.7 (High)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/golang-jwt/jwt/v5"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.0.0-rc.1"
            },
            {
              "fixed": "5.2.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/golang-jwt/jwt/v4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.5.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/golang-jwt/jwt"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.2.0"
            },
            {
              "last_affected": "3.2.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-30204"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-405"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-03-21T22:04:00Z",
    "nvd_published_at": "2025-03-21T22:15:26Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nFunction [`parse.ParseUnverified`](https://github.com/golang-jwt/jwt/blob/c035977d9e11c351f4c05dfeae193923cbab49ee/parser.go#L138-L139) currently splits (via a call to [strings.Split](https://pkg.go.dev/strings#Split)) its argument (which is untrusted data) on periods.\n\nAs a result, in the face of a malicious request whose _Authorization_ header consists of `Bearer ` followed by many period characters, a call to that function incurs allocations to the tune of O(n) bytes (where n stands for the length of the function\u0027s argument), with a constant factor of about 16. Relevant weakness: [CWE-405: Asymmetric Resource Consumption (Amplification)](https://cwe.mitre.org/data/definitions/405.html)\n\n### Details\n\nSee [`parse.ParseUnverified`](https://github.com/golang-jwt/jwt/blob/c035977d9e11c351f4c05dfeae193923cbab49ee/parser.go#L138-L139) \n\n### Impact\n\nExcessive memory allocation",
  "id": "GHSA-mh63-6h87-95cp",
  "modified": "2025-04-10T13:02:34Z",
  "published": "2025-03-21T22:04:00Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/golang-jwt/jwt/security/advisories/GHSA-mh63-6h87-95cp"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-30204"
    },
    {
      "type": "WEB",
      "url": "https://github.com/golang-jwt/jwt/commit/0951d184286dece21f73c85673fd308786ffe9c3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/golang-jwt/jwt/commit/bf316c48137a1212f8d0af9288cc9ce8e59f1afb"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/golang-jwt/jwt"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20250404-0002"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "jwt-go allows excessive memory allocation during header parsing"
}

GHSA-P77J-4MVH-X3M3

Vulnerability from github – Published: 2026-03-18 20:10 – Updated: 2026-03-25 18:12

Summary

gRPC-Go has an authorization bypass via missing leading slash in :path

Details

Impact

What kind of vulnerability is it? Who is impacted?

It is an Authorization Bypass resulting from Improper Input Validation of the HTTP/2 :path pseudo-header.

The gRPC-Go server was too lenient in its routing logic, accepting requests where the :path omitted the mandatory leading slash (e.g., Service/Method instead of /Service/Method). While the server successfully routed these requests to the correct handler, authorization interceptors (including the official grpc/authz package) evaluated the raw, non-canonical path string. Consequently, "deny" rules defined using canonical paths (starting with /) failed to match the incoming request, allowing it to bypass the policy if a fallback "allow" rule was present.

Who is impacted? This affects gRPC-Go servers that meet both of the following criteria: 1. They use path-based authorization interceptors, such as the official RBAC implementation in google.golang.org/grpc/authz or custom interceptors relying on info.FullMethod or grpc.Method(ctx). 2. Their security policy contains specific "deny" rules for canonical paths but allows other requests by default (a fallback "allow" rule).

The vulnerability is exploitable by an attacker who can send raw HTTP/2 frames with malformed :path headers directly to the gRPC server.

Patches

Has the problem been patched? What versions should users upgrade to?

Yes, the issue has been patched. The fix ensures that any request with a :path that does not start with a leading slash is immediately rejected with a codes.Unimplemented error, preventing it from reaching authorization interceptors or handlers with a non-canonical path string.

Users should upgrade to the following versions (or newer): * v1.79.3 * The latest master branch.

It is recommended that all users employing path-based authorization (especially grpc/authz) upgrade as soon as the patch is available in a tagged release.

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

While upgrading is the most secure and recommended path, users can mitigate the vulnerability using one of the following methods:

1. Use a Validating Interceptor (Recommended Mitigation)

Add an "outermost" interceptor to your server that validates the path before any other authorization logic runs:

func pathValidationInterceptor(ctx context.Context, req any, info *grpc.UnaryServerInfo, handler grpc.UnaryHandler) (any, error) {
    if info.FullMethod == "" || info.FullMethod[0] != '/' {
        return nil, status.Errorf(codes.Unimplemented, "malformed method name")
    }   
    return handler(ctx, req)
}

// Ensure this is the FIRST interceptor in your chain
s := grpc.NewServer(
    grpc.ChainUnaryInterceptor(pathValidationInterceptor, authzInterceptor),
)

2. Infrastructure-Level Normalization

If your gRPC server is behind a reverse proxy or load balancer (such as Envoy, NGINX, or an L7 Cloud Load Balancer), ensure it is configured to enforce strict HTTP/2 compliance for pseudo-headers and reject or normalize requests where the :path header does not start with a leading slash.

3. Policy Hardening

Switch to a "default deny" posture in your authorization policies (explicitly listing all allowed paths and denying everything else) to reduce the risk of bypasses via malformed inputs.

Severity

9.1 (Critical)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "google.golang.org/grpc"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.79.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33186"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-285"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-18T20:10:29Z",
    "nvd_published_at": "2026-03-20T23:16:45Z",
    "severity": "CRITICAL"
  },
  "details": "### Impact\n_What kind of vulnerability is it? Who is impacted?_\n\nIt is an **Authorization Bypass** resulting from **Improper Input Validation** of the HTTP/2 `:path` pseudo-header.\n\nThe gRPC-Go server was too lenient in its routing logic, accepting requests where the `:path` omitted the mandatory leading slash (e.g., `Service/Method` instead of `/Service/Method`). While the server successfully routed these requests to the correct handler, authorization interceptors (including the official `grpc/authz` package) evaluated the raw, non-canonical path string. Consequently, \"deny\" rules defined using canonical paths (starting with `/`) failed to match the incoming request, allowing it to bypass the policy if a fallback \"allow\" rule was present.\n\n**Who is impacted?**\nThis affects gRPC-Go servers that meet both of the following criteria:\n1. They use path-based authorization interceptors, such as the official RBAC implementation in `google.golang.org/grpc/authz` or custom interceptors relying on `info.FullMethod` or `grpc.Method(ctx)`.\n2. Their security policy contains specific \"deny\" rules for canonical paths but allows other requests by default (a fallback \"allow\" rule).\n\nThe vulnerability is exploitable by an attacker who can send raw HTTP/2 frames with malformed `:path` headers directly to the gRPC server.\n\n### Patches\n_Has the problem been patched? What versions should users upgrade to?_\n\nYes, the issue has been patched. The fix ensures that any request with a `:path` that does not start with a leading slash is immediately rejected with a `codes.Unimplemented` error, preventing it from reaching authorization interceptors or handlers with a non-canonical path string.\n\nUsers should upgrade to the following versions (or newer):\n* **v1.79.3**\n* The latest **master** branch.\n\nIt is recommended that all users employing path-based authorization (especially `grpc/authz`) upgrade as soon as the patch is available in a tagged release.\n\n### Workarounds\n_Is there a way for users to fix or remediate the vulnerability without upgrading?_\n\nWhile upgrading is the most secure and recommended path, users can mitigate the vulnerability using one of the following methods:\n\n#### 1. Use a Validating Interceptor (Recommended Mitigation)\nAdd an \"outermost\" interceptor to your server that validates the path before any other authorization logic runs:\n\n```go\nfunc pathValidationInterceptor(ctx context.Context, req any, info *grpc.UnaryServerInfo, handler grpc.UnaryHandler) (any, error) {\n    if info.FullMethod == \"\" || info.FullMethod[0] != \u0027/\u0027 {\n        return nil, status.Errorf(codes.Unimplemented, \"malformed method name\")\n    }   \n    return handler(ctx, req)\n}\n\n// Ensure this is the FIRST interceptor in your chain\ns := grpc.NewServer(\n    grpc.ChainUnaryInterceptor(pathValidationInterceptor, authzInterceptor),\n)\n```\n\n#### 2. Infrastructure-Level Normalization\nIf your gRPC server is behind a reverse proxy or load balancer (such as Envoy, NGINX, or an L7 Cloud Load Balancer), ensure it is configured to enforce strict HTTP/2 compliance for pseudo-headers and reject or normalize requests where the `:path` header does not start with a leading slash.\n\n#### 3. Policy Hardening\nSwitch to a \"default deny\" posture in your authorization policies (explicitly listing all allowed paths and denying everything else) to reduce the risk of bypasses via malformed inputs.",
  "id": "GHSA-p77j-4mvh-x3m3",
  "modified": "2026-03-25T18:12:09Z",
  "published": "2026-03-18T20:10:29Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/grpc/grpc-go/security/advisories/GHSA-p77j-4mvh-x3m3"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33186"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/grpc/grpc-go"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "gRPC-Go has an authorization bypass via missing leading slash in :path"
}

GHSA-QXP5-GWG8-XV66

Vulnerability from github – Published: 2025-03-12 22:06 – Updated: 2026-04-24 20:36

Summary

HTTP Proxy bypass using IPv6 Zone IDs in golang.org/x/net

Details

Matching of hosts against proxy patterns can improperly treat an IPv6 zone ID as a hostname component. For example, when the NO_PROXY environment variable is set to "*.example.com", a request to "[::1%25.example.com]:80` will incorrectly match and not be proxied.

Severity

4.4 (Medium)


                  
                    CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:L

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "golang.org/x/net"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.36.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-22870"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-115",
      "CWE-20"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-03-12T22:06:40Z",
    "nvd_published_at": "2025-03-12T19:15:38Z",
    "severity": "MODERATE"
  },
  "details": "Matching of hosts against proxy patterns can improperly treat an IPv6 zone ID as a hostname component. For example, when the NO_PROXY environment variable is set to \"*.example.com\", a request to \"[::1%25.example.com]:80` will incorrectly match and not be proxied.",
  "id": "GHSA-qxp5-gwg8-xv66",
  "modified": "2026-04-24T20:36:12Z",
  "published": "2025-03-12T22:06:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22870"
    },
    {
      "type": "PACKAGE",
      "url": "https://go-review.googlesource.com/q/project:net"
    },
    {
      "type": "WEB",
      "url": "https://go.dev/cl/654697"
    },
    {
      "type": "WEB",
      "url": "https://go.dev/issue/71984"
    },
    {
      "type": "WEB",
      "url": "https://groups.google.com/g/golang-announce/c/4t3lzH3I0eI/m/b42ImqrBAQAJ"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2025-3503"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20250509-0007"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2025/03/07/2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "HTTP Proxy bypass using IPv6 Zone IDs in golang.org/x/net"
}

GHSA-VFFH-X6R8-XX99

Vulnerability from github – Published: 2026-04-13 16:39 – Updated: 2026-04-27 16:21

Summary

Prometheus has Stored XSS via metric names and label values in Prometheus web UI tooltips and metrics explorer

Details

Impact

Stored cross-site scripting (XSS) via crafted metric names in the Prometheus web UI:

Old React UI + New Mantine UI: When a user hovers over a chart tooltip on the Graph page, metric names containing HTML/JavaScript are injected into innerHTML without escaping, causing arbitrary script execution in the user's browser.
Old React UI only: When a user opens the Metric Explorer (globe icon next to the PromQL expression input field), and a metric name containing HTML/JavaScript is rendered in the fuzzy search results, it is injected into innerHTML without escaping, causing arbitrary script execution in the user's browser.
Old React UI only: When a user views a heatmap chart and hovers over a cell, the le label values of the underlying histogram buckets are interpolated into innerHTML without escaping. While le is conventionally a numeric bucket boundary, Prometheus does not enforce this — arbitrary UTF-8 strings are accepted as label values, allowing script injection via a crafted scrape target or remote write.

With Prometheus v3.x defaulting to UTF-8 metric and label name validation, characters like <, >, and " are now valid in metric names and labels, making this exploitable.

An attacker who can inject metrics (via a compromised scrape target, remote write, or OTLP receiver endpoint) can execute JavaScript in the browser of any Prometheus user who views the metric in the Graph UI. From the XSS context, an attacker could for example:

Read /api/v1/status/config to extract sensitive configuration (although credentials / secrets are redacted by the server)
Call /-/quit to shut down Prometheus (only if --web.enable-lifecycle is set)
Call /api/v1/admin/tsdb/delete_series to delete data (only if --web.enable-admin-api is set)
Exfiltrate metric data to an external server

Both the new Mantine UI and the old React UI are affected. The vulnerable code paths are:

web/ui/mantine-ui/src/pages/query/uPlotChartHelpers.ts — tooltip innerHTML with unescaped labels.__name__
web/ui/react-app/src/pages/graph/GraphHelpers.ts — tooltip content with unescaped labels.__name__
web/ui/react-app/src/pages/graph/MetricsExplorer.tsx — fuzzy search results rendered via dangerouslySetInnerHTML without sanitization
web/ui/react-app/src/vendor/flot/jquery.flot.heatmap.js — heatmap tooltip with unescaped label values

Patches

A patch has been published in Prometheus 3.5.2 LTS and Prometheus 3.11.2. The fix applies escapeHTML() to all user-controlled values (metric names and label values) before inserting them into innerHTML. This advisory will be updated with the patched version once released.

Workarounds

If using the remote write receiver (--web.enable-remote-write-receiver), ensure it is not exposed to untrusted sources.
If using the OTLP receiver (--web.enable-otlp-receiver), ensure it is not exposed to untrusted sources.
Ensure scrape targets are trusted and not under attacker control.
Do not enable admin / mutating API endpoints (e.g. --web.enable-admin-api or web.enable-lifecycle) in cases where you cannot prevent untrusted data from being ingested.
Users should avoid clicking untrusted links, especially those containing functions such as label_replace, as they may generate poisoned label names and values.

Acknowledgements

Thanks to @gladiator9797 (Duc Anh Nguyen from TinyxLab) for reporting this.

Severity

6.1 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N

5.3 (Medium)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/prometheus/prometheus"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "last_affected": "3.5.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/prometheus/prometheus"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.6.0"
            },
            {
              "last_affected": "3.11.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/prometheus/prometheus"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.311.2-0.20260410083055-07c6232d159b"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-40179"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-79"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-13T16:39:16Z",
    "nvd_published_at": "2026-04-15T23:16:09Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nStored cross-site scripting (XSS) via crafted metric names in the Prometheus web UI:\n\n* **Old React UI + New Mantine UI:** When a user hovers over a chart tooltip on the Graph page, metric names containing HTML/JavaScript are injected into `innerHTML` without escaping, causing arbitrary script execution in the user\u0027s browser.\n* **Old React UI only:** When a user opens the Metric Explorer (globe icon next to the PromQL expression input field), and a metric name containing HTML/JavaScript is rendered in the fuzzy search results, it is injected into `innerHTML` without escaping, causing arbitrary script execution in the user\u0027s browser.\n* **Old React UI only:** When a user views a heatmap chart and hovers over a cell, the `le` label values of the underlying histogram buckets are interpolated into `innerHTML` without escaping. While `le` is conventionally a numeric bucket boundary, Prometheus does not enforce this \u2014 arbitrary UTF-8 strings are accepted as label values, allowing script injection via a crafted scrape target or remote write.\n\nWith Prometheus v3.x defaulting to UTF-8 metric and label name validation, characters like `\u003c`, `\u003e`, and `\"` are now valid in metric names and labels, making this exploitable.\n\nAn attacker who can inject metrics (via a compromised scrape target, remote write, or OTLP receiver endpoint) can execute JavaScript in the browser of any Prometheus user who views the metric in the Graph UI. From the XSS context, an attacker could for example:\n\n- Read `/api/v1/status/config` to extract sensitive configuration (although credentials / secrets are redacted by the server)\n- Call `/-/quit` to shut down Prometheus (only if `--web.enable-lifecycle` is set)\n- Call `/api/v1/admin/tsdb/delete_series` to delete data (only if `--web.enable-admin-api` is set)\n- Exfiltrate metric data to an external server\n\nBoth the new Mantine UI and the old React UI are affected. The vulnerable code paths are:\n\n- `web/ui/mantine-ui/src/pages/query/uPlotChartHelpers.ts` \u2014 tooltip `innerHTML` with unescaped `labels.__name__`\n- `web/ui/react-app/src/pages/graph/GraphHelpers.ts` \u2014 tooltip content with unescaped `labels.__name__`\n- `web/ui/react-app/src/pages/graph/MetricsExplorer.tsx` \u2014 fuzzy search results rendered via `dangerouslySetInnerHTML` without sanitization\n- `web/ui/react-app/src/vendor/flot/jquery.flot.heatmap.js` \u2014 heatmap tooltip with unescaped label values\n\n### Patches\n\nA patch has been published in Prometheus 3.5.2 LTS and Prometheus 3.11.2. The fix applies `escapeHTML()` to all user-controlled values (metric names and label values) before inserting them into `innerHTML`. This advisory will be updated with the patched version once released.\n\n### Workarounds\n\n- If using the remote write receiver (`--web.enable-remote-write-receiver`), ensure it is not exposed to untrusted sources.\n- If using the OTLP receiver (`--web.enable-otlp-receiver`), ensure it is not exposed to untrusted sources.\n- Ensure scrape targets are trusted and not under attacker control.\n- Do not enable admin / mutating API endpoints (e.g. `--web.enable-admin-api` or `web.enable-lifecycle`) in cases where you cannot prevent untrusted data from being ingested.\n- Users should avoid clicking untrusted links, especially those containing functions such as label_replace, as they may generate poisoned label names and values.\n\n### Acknowledgements\n\nThanks to @gladiator9797 (Duc Anh Nguyen from TinyxLab) for reporting this.",
  "id": "GHSA-vffh-x6r8-xx99",
  "modified": "2026-04-27T16:21:30Z",
  "published": "2026-04-13T16:39:16Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/prometheus/prometheus/security/advisories/GHSA-vffh-x6r8-xx99"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40179"
    },
    {
      "type": "WEB",
      "url": "https://github.com/prometheus/prometheus/pull/18506"
    },
    {
      "type": "WEB",
      "url": "https://github.com/prometheus/prometheus/commit/07c6232d159bfb474a077788be184d87adcfac3c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/prometheus/prometheus"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Prometheus has Stored XSS via metric names and label values in Prometheus web UI tooltips and metrics explorer"
}

GHSA-VVGC-356P-C3XW

Vulnerability from github – Published: 2025-04-16 19:22 – Updated: 2025-05-17 18:49

Summary

golang.org/x/net vulnerable to Cross-site Scripting

Details

The tokenizer incorrectly interprets tags with unquoted attribute values that end with a solidus character (/) as self-closing. When directly using Tokenizer, this can result in such tags incorrectly being marked as self-closing, and when using the Parse functions, this can result in content following such tags as being placed in the wrong scope during DOM construction, but only when tags are in foreign content (e.g. , , etc contexts).

Severity

5.3 (Medium)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "golang.org/x/net"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.38.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-22872"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-79"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-04-16T19:22:51Z",
    "nvd_published_at": "2025-04-16T18:16:04Z",
    "severity": "MODERATE"
  },
  "details": "The tokenizer incorrectly interprets tags with unquoted attribute values that end with a solidus character (/) as self-closing. When directly using Tokenizer, this can result in such tags incorrectly being marked as self-closing, and when using the Parse functions, this can result in content following such tags as being placed in the wrong scope during DOM construction, but only when tags are in foreign content (e.g. \u003cmath\u003e, \u003csvg\u003e, etc contexts).",
  "id": "GHSA-vvgc-356p-c3xw",
  "modified": "2025-05-17T18:49:25Z",
  "published": "2025-04-16T19:22:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22872"
    },
    {
      "type": "WEB",
      "url": "https://go.dev/cl/662715"
    },
    {
      "type": "WEB",
      "url": "https://go.dev/issue/73070"
    },
    {
      "type": "WEB",
      "url": "https://groups.google.com/g/golang-announce/c/ezSKR9vqbqA"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2025-3595"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20250516-0007"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "golang.org/x/net vulnerable to Cross-site Scripting"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Detection rules are retrieved from Rulezet.

Action not permitted

Vulnerability from cleanstart

GHSA-MH63-6H87-95CP

Summary

Details

Impact

GHSA-P77J-4MVH-X3M3

Impact

Patches

Workarounds

1. Use a Validating Interceptor (Recommended Mitigation)

2. Infrastructure-Level Normalization

3. Policy Hardening

GHSA-QXP5-GWG8-XV66

GHSA-VFFH-X6R8-XX99

Impact

Patches

Workarounds

Acknowledgements

GHSA-VVGC-356P-C3XW

Tags

Sightings

Nomenclature