The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applicationsThere is no fixed version for RHEL:10 grafana.
Note: Versions mentioned in the description apply only to the upstream grafana package and not the grafana package as distributed by RHEL.
See How to fix? for RHEL:10 relevant fixed versions and status.
Zod schema-validation library contains an uncontrolled resource consumption vulnerability that allows attackers to exhaust memory by submitting a large array, set or map to an application that uses a container schema without an explicit size constraint. The handleArrayResult parse logic in $ZodArray (and the equivalent set and map paths) accumulates every validation issue for each failing element with no cap or early termination, causing the process to allocate one issue object per element and crash under out-of-memory conditions. This is reachable in the default configuration whenever a container schema such as z.array() is declared without a size bound. The upstream change in commit e06a510 (pull request 6652, first released in 4.6.6) only moves the .max(), .length() and .size() size checks to run before element parsing, so it rejects oversized input for schemas that declare an explicit upper bound; per the maintainer, unbounded containers are unchanged. No released version remediates the unbounded (default) case described here, and an opt-in setting to cap total accumulated errors was proposed but not merged.