RHSA-2026:63164HighCVSS 8.3

Red Hat Security Advisory: Red Hat Hardened Images RPMs bug fix and enhancement update

Published
September 3, 2026
Last Modified
September 11, 2026

🔗 CVE IDs covered (8)

📋 Description

CVE-2026-8595 — grafana: Grafana: Stored Cross-Site Scripting via malicious dashboard field name CVE-2026-8609 — grafana: Grafana: Denial of Service via unbounded memory growth in OAuth login route CVE-2026-9765 — grafana: Grafana: Privilege escalation via broken access control CVE-2026-21723 — grafana: Grafana: Denial of Service via uncontrolled memory usage in alertmanager templates CVE-2026-33382 — grafana: Grafana: Denial of Service via excessive memory allocation from large API request payloads CVE-2026-82417 — qs: qs: Denial of Service via improper validation in stringify function CVE-2026-82562 — qs: qs: Denial of Service via array limit bypass in query string parsing CVE-2026-84375 — js-yaml: js-yaml: Denial of Service vulnerability in YAML parsing

🎯 Affected products4

  • Red Hat Hardened Images
  • grafana13-2-main@aarch64 as a component of Red Hat Hardened Images
  • grafana13-2-main@src as a component of Red Hat Hardened Images
  • grafana13-2-main@x86_64 as a component of Red Hat Hardened Images

✅ Remediation

For details on how to apply this update, which includes the changes described in this advisory, refer to: https://images.redhat.com/ Workaround: To mitigate this issue, restrict network access to the Grafana instance to trusted internal networks or localhost. If a reverse proxy or load balancer is deployed in front of Grafana, configure it to implement rate limiting on requests to the OAuth login endpoint to prevent an attacker from exhausting system resources. If OAuth is not required, consider disabling it in the Grafana configuration, though this may impact user authentication workflows. Workaround: If not required, disable anonymous access to prevent unauthenticated exploitation of the Alertmanager templates test endpoint. Refer to Grafana’s official documentation for configuration details. To protect against low-privileged authenticated users triggering this flaw, configure a reverse proxy or WAF to block or strictly rate-limit traffic to /api/alertmanager/grafana/config/api/v1/templates/test. Workaround: Deploy a reverse proxy or API gateway (e.g., Nginx) in front of Grafana configured to strictly limit the maximum HTTP request body size, dropping oversized payloads before they reach the backend. As a defense-in-depth measure, restrict network access to trusted internal clients via firewall rules. Note: Applying these proxy and network changes may require a service reload, causing a temporary interruption. Workaround: If an immediate upgrade to qs 6.16.0 is not feasible, avoid re-serializing attacker-influenced parsed query or body objects with qs.stringify. Where qs.parse is used directly, set allowPrototypes: false unless prototype keys are required. For Express applications, review whether the default query parser configuration is necessary. Wrapping qs.stringify calls in try/catch can limit impact to individual requests. Workaround: Until an updated qs dependency is available in your Red Hat product, limit exposure as follows: 1. If your application calls qs.parse() directly, avoid enabling both comma:true and throwOnLimitExceeded:true when parsing untrusted query strings or urlencoded request bodies. Disable one of these non-default options, or upgrade qs to version 6.16.0 or later. 2. Where qs is included only as a transitive dependency, apply product updates that ship qs 6.16.0 or later when they become available. 3. Enforce HTTP request-line and request-body size limits at your ingress or application server. Because allocated memory scales with attacker-supplied input size, transport-layer limits bound worst-case impact. Host operating systems are not directly affected. These steps apply to application processes that use qs with the vulnerable configuration.

🔗 References (14)