Skip to content

RUSTSEC-2025-0070 CVE-2025-8671 GHSA-mrjm-qq9m-9mjq

Pingora MadeYouReset HTTP/2 vulnerability

High crates.io
Severity
7.5 / 10
High · CVSS 3.1
Exploit chance (EPSS)
3.62%
Chance of exploitation in the next 30 days. Higher than 89.52% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-404 Improper Resource Shutdown or Release
Fix
0.6.0
Upgrade pingora-core to this version or later

Description

Pingora deployments using versions prior to 0.6.0 that include HTTP/2 server support may be affected by the vulnerability described in CVE-2025-8671. Under certain conditions, Pingora applications may allocate buffers before the HTTP/2 reset and resulting stream cancellation is processed by the server. Repeated resets can force excessive memory consumption and lead to denial-of-service.

On affected versions, malicious clients could trigger unusually high memory consumption, which may result in service instability or process termination.

This issue is addressed by ensuring Pingora uses patched versions of HTTP/2 dependencies that include reset-handling safeguards to release connection resources before excessive memory buildup. Users are requested to upgrade to versions >= 0.6.0, which incorporates the required fixes.

Affected versions

crates.io

PackageVulnerableFixed in
pingora-core
>= 0.0.0-0, < 0.6.0
0.6.0

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

pingora-core crates.io → 0.6.0

cargo
cargo update -p pingora-core --precise 0.6.0

Severity breakdown

CVSS 3.1 7.5

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

Attack vector
Network
Attack complexity
Low
Privileges required
None
User interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Weakness

CWE-404: Improper Resource Shutdown or Release

The product does not release or incorrectly releases a resource before it is made available for re-use.

How to prevent it
  • Requirements: Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, languages such as Java, Ruby, and Lisp perform automatic garbage collection that releases memory for objects that have been deallocated.
  • Implementation: It is good practice to be responsible for freeing all resources you allocate and to be consistent with how and where you free memory in a function. If you allocate memory that you intend to free upon completion of the function, you must be sure to free the memory at all exit points for that function including error conditions.
  • Implementation: Memory should be allocated/freed using matching functions such as malloc/free, new/delete, and new[]/delete[].
  • Implementation: When releasing a complex object or structure, ensure that you properly dispose of all of its member components, not just the object itself.

References

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
RUSTSEC-2026-0388
Pingora HTTP/2 :authority and Host header mismatch enables cache poisoning and host-based access control bypass
Not rated yet Also affects pingora-core
RUSTSEC-2026-0389
Pingora HTTP/2 server memory exhaustion through unbounded default header-list and concurrent-stream limits
High Also affects pingora-core
GHSA-xq2h-p299-vjwv
Pingora vulnerable to HTTP Request Smuggling via Premature Upgrade
Critical Also affects pingora-core
GHSA-hj7x-879w-vrp7
Pingora has HTTP Request Smuggling via HTTP/1.0 and Transfer-Encoding Misparsing
Critical Also affects pingora-core
GHSA-393w-9x6h-8gc7
Pingora update for MadeYouReset HTTP/2 vulnerability
High Also affects pingora-core
GHSA-93c7-7xqw-w357
Pingora has a Request Smuggling Vulnerability
Medium Also affects pingora-core
PYSEC-2026-4319
A security flaw has been discovered in vllm-project vLLM up to 0.31.0.
Medium Same weakness, CWE-404
PYSEC-2026-4186
A flaw has been found in vllm-project vLLM up to 0.26.0.
Medium Same weakness, CWE-404
Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor