pingora-cache
A library for building fast, reliable and evolvable network services.
Activity
- Latest release
- 4d ago
- Total releases
- 11
- Cadence
- ~3 months
- Last 12 months
- 4
Reach
- Downloads
- 9.3M
- Stars
- 27.4k
Details
- License
- Apache-2.0
- First release
- Feb 28, 2024
| Version | Released | |
|---|---|---|
0.9.0
minor
|
0.9.0
minor
Dependencies (37)
+ 29 more
Changelog
Compare changes
|
|
0.8.1
unknown
|
0.8.1
unknown
Dependencies (34)
+ 26 more
Changelog
Compare changes
|
|
0.8.0
unknown
|
0.8.0
unknown
Dependencies (34)
+ 26 more
Changelog
Compare changes
|
|
0.7.0
unknown
1 CVE
CVE-2026-2836
GHSA-f93w-pcj3-rggc
RUSTSEC-2026-0035
Mar 05, 2026
Pingora vulnerable to cache poisoning via insecure-by-default cache key
High
Network
Low
None
ImpactPingora versions prior to 0.8.0 generated cache keys using only the URI path, excluding critical factors such as the host header. This allows an attacker to poison the cache and serve cross-origin responses to users. This vulnerability affects users of Pingora's alpha proxy caching feature who relied on the default CacheKey implementation. An attacker could exploit this for cross-tenant data leakage in multi-tenant deployments, or serve malicious content to legitimate users by poisoning shared cache entries. Note: Cloudflare customers and Cloudflare's CDN infrastructure were not affected by this vulnerability, as Cloudflare's default cache key implementation uses multiple factors to prevent cache key poisoning and never made use of the previously provided default. PatchesWe strongly suggest users should upgrade to Pingora v.0.8.0 or higher, which removes the default CacheKey implementation. WorkaroundsDo not rely on the provided CacheKey default, and at minimum use the host / :authority and the upstream peer TLS scheme as part of building the CacheKey, as well as other factors that may apply to the deployment e.g. HTTP method. ReferencesSee CVE-2026-2836 and the Cloudflare blog post for more details. CreditsDisclosed responsibly by Rajat Raghav (@xclow3n) through the Cloudflare Bug Bounty Program. Fixed in
0.8.0
References Updated Mar 09, 2026 · Source: OSV.dev |
0.7.0
unknown
Dependencies (34)
+ 26 more
Changelog
Compare changes
|
|
0.6.0
unknown
1 CVE
CVE-2026-2836
GHSA-f93w-pcj3-rggc
RUSTSEC-2026-0035
Mar 05, 2026
Pingora vulnerable to cache poisoning via insecure-by-default cache key
High
Network
Low
None
ImpactPingora versions prior to 0.8.0 generated cache keys using only the URI path, excluding critical factors such as the host header. This allows an attacker to poison the cache and serve cross-origin responses to users. This vulnerability affects users of Pingora's alpha proxy caching feature who relied on the default CacheKey implementation. An attacker could exploit this for cross-tenant data leakage in multi-tenant deployments, or serve malicious content to legitimate users by poisoning shared cache entries. Note: Cloudflare customers and Cloudflare's CDN infrastructure were not affected by this vulnerability, as Cloudflare's default cache key implementation uses multiple factors to prevent cache key poisoning and never made use of the previously provided default. PatchesWe strongly suggest users should upgrade to Pingora v.0.8.0 or higher, which removes the default CacheKey implementation. WorkaroundsDo not rely on the provided CacheKey default, and at minimum use the host / :authority and the upstream peer TLS scheme as part of building the CacheKey, as well as other factors that may apply to the deployment e.g. HTTP method. ReferencesSee CVE-2026-2836 and the Cloudflare blog post for more details. CreditsDisclosed responsibly by Rajat Raghav (@xclow3n) through the Cloudflare Bug Bounty Program. Fixed in
0.8.0
References Updated Mar 09, 2026 · Source: OSV.dev |
0.6.0
unknown
Dependencies (33)
+ 25 more
Changelog
Compare changes
|
|
0.5.0
unknown
1 CVE
CVE-2026-2836
GHSA-f93w-pcj3-rggc
RUSTSEC-2026-0035
Mar 05, 2026
Pingora vulnerable to cache poisoning via insecure-by-default cache key
High
Network
Low
None
ImpactPingora versions prior to 0.8.0 generated cache keys using only the URI path, excluding critical factors such as the host header. This allows an attacker to poison the cache and serve cross-origin responses to users. This vulnerability affects users of Pingora's alpha proxy caching feature who relied on the default CacheKey implementation. An attacker could exploit this for cross-tenant data leakage in multi-tenant deployments, or serve malicious content to legitimate users by poisoning shared cache entries. Note: Cloudflare customers and Cloudflare's CDN infrastructure were not affected by this vulnerability, as Cloudflare's default cache key implementation uses multiple factors to prevent cache key poisoning and never made use of the previously provided default. PatchesWe strongly suggest users should upgrade to Pingora v.0.8.0 or higher, which removes the default CacheKey implementation. WorkaroundsDo not rely on the provided CacheKey default, and at minimum use the host / :authority and the upstream peer TLS scheme as part of building the CacheKey, as well as other factors that may apply to the deployment e.g. HTTP method. ReferencesSee CVE-2026-2836 and the Cloudflare blog post for more details. CreditsDisclosed responsibly by Rajat Raghav (@xclow3n) through the Cloudflare Bug Bounty Program. Fixed in
0.8.0
References Updated Mar 09, 2026 · Source: OSV.dev |
0.5.0
unknown
Dependencies (32)
+ 24 more
Changelog
Compare changes
|
|
0.4.0
unknown
1 CVE
CVE-2026-2836
GHSA-f93w-pcj3-rggc
RUSTSEC-2026-0035
Mar 05, 2026
Pingora vulnerable to cache poisoning via insecure-by-default cache key
High
Network
Low
None
ImpactPingora versions prior to 0.8.0 generated cache keys using only the URI path, excluding critical factors such as the host header. This allows an attacker to poison the cache and serve cross-origin responses to users. This vulnerability affects users of Pingora's alpha proxy caching feature who relied on the default CacheKey implementation. An attacker could exploit this for cross-tenant data leakage in multi-tenant deployments, or serve malicious content to legitimate users by poisoning shared cache entries. Note: Cloudflare customers and Cloudflare's CDN infrastructure were not affected by this vulnerability, as Cloudflare's default cache key implementation uses multiple factors to prevent cache key poisoning and never made use of the previously provided default. PatchesWe strongly suggest users should upgrade to Pingora v.0.8.0 or higher, which removes the default CacheKey implementation. WorkaroundsDo not rely on the provided CacheKey default, and at minimum use the host / :authority and the upstream peer TLS scheme as part of building the CacheKey, as well as other factors that may apply to the deployment e.g. HTTP method. ReferencesSee CVE-2026-2836 and the Cloudflare blog post for more details. CreditsDisclosed responsibly by Rajat Raghav (@xclow3n) through the Cloudflare Bug Bounty Program. Fixed in
0.8.0
References Updated Mar 09, 2026 · Source: OSV.dev | ||
0.3.0
unknown
1 CVE
CVE-2026-2836
GHSA-f93w-pcj3-rggc
RUSTSEC-2026-0035
Mar 05, 2026
Pingora vulnerable to cache poisoning via insecure-by-default cache key
High
Network
Low
None
ImpactPingora versions prior to 0.8.0 generated cache keys using only the URI path, excluding critical factors such as the host header. This allows an attacker to poison the cache and serve cross-origin responses to users. This vulnerability affects users of Pingora's alpha proxy caching feature who relied on the default CacheKey implementation. An attacker could exploit this for cross-tenant data leakage in multi-tenant deployments, or serve malicious content to legitimate users by poisoning shared cache entries. Note: Cloudflare customers and Cloudflare's CDN infrastructure were not affected by this vulnerability, as Cloudflare's default cache key implementation uses multiple factors to prevent cache key poisoning and never made use of the previously provided default. PatchesWe strongly suggest users should upgrade to Pingora v.0.8.0 or higher, which removes the default CacheKey implementation. WorkaroundsDo not rely on the provided CacheKey default, and at minimum use the host / :authority and the upstream peer TLS scheme as part of building the CacheKey, as well as other factors that may apply to the deployment e.g. HTTP method. ReferencesSee CVE-2026-2836 and the Cloudflare blog post for more details. CreditsDisclosed responsibly by Rajat Raghav (@xclow3n) through the Cloudflare Bug Bounty Program. Fixed in
0.8.0
References Updated Mar 09, 2026 · Source: OSV.dev | ||
0.2.0
unknown
1 CVE
CVE-2026-2836
GHSA-f93w-pcj3-rggc
RUSTSEC-2026-0035
Mar 05, 2026
Pingora vulnerable to cache poisoning via insecure-by-default cache key
High
Network
Low
None
ImpactPingora versions prior to 0.8.0 generated cache keys using only the URI path, excluding critical factors such as the host header. This allows an attacker to poison the cache and serve cross-origin responses to users. This vulnerability affects users of Pingora's alpha proxy caching feature who relied on the default CacheKey implementation. An attacker could exploit this for cross-tenant data leakage in multi-tenant deployments, or serve malicious content to legitimate users by poisoning shared cache entries. Note: Cloudflare customers and Cloudflare's CDN infrastructure were not affected by this vulnerability, as Cloudflare's default cache key implementation uses multiple factors to prevent cache key poisoning and never made use of the previously provided default. PatchesWe strongly suggest users should upgrade to Pingora v.0.8.0 or higher, which removes the default CacheKey implementation. WorkaroundsDo not rely on the provided CacheKey default, and at minimum use the host / :authority and the upstream peer TLS scheme as part of building the CacheKey, as well as other factors that may apply to the deployment e.g. HTTP method. ReferencesSee CVE-2026-2836 and the Cloudflare blog post for more details. CreditsDisclosed responsibly by Rajat Raghav (@xclow3n) through the Cloudflare Bug Bounty Program. Fixed in
0.8.0
References Updated Mar 09, 2026 · Source: OSV.dev | ||
0.1.1
unknown
1 CVE
CVE-2026-2836
GHSA-f93w-pcj3-rggc
RUSTSEC-2026-0035
Mar 05, 2026
Pingora vulnerable to cache poisoning via insecure-by-default cache key
High
Network
Low
None
ImpactPingora versions prior to 0.8.0 generated cache keys using only the URI path, excluding critical factors such as the host header. This allows an attacker to poison the cache and serve cross-origin responses to users. This vulnerability affects users of Pingora's alpha proxy caching feature who relied on the default CacheKey implementation. An attacker could exploit this for cross-tenant data leakage in multi-tenant deployments, or serve malicious content to legitimate users by poisoning shared cache entries. Note: Cloudflare customers and Cloudflare's CDN infrastructure were not affected by this vulnerability, as Cloudflare's default cache key implementation uses multiple factors to prevent cache key poisoning and never made use of the previously provided default. PatchesWe strongly suggest users should upgrade to Pingora v.0.8.0 or higher, which removes the default CacheKey implementation. WorkaroundsDo not rely on the provided CacheKey default, and at minimum use the host / :authority and the upstream peer TLS scheme as part of building the CacheKey, as well as other factors that may apply to the deployment e.g. HTTP method. ReferencesSee CVE-2026-2836 and the Cloudflare blog post for more details. CreditsDisclosed responsibly by Rajat Raghav (@xclow3n) through the Cloudflare Bug Bounty Program. Fixed in
0.8.0
References Updated Mar 09, 2026 · Source: OSV.dev | ||
0.1.0
unknown
1 CVE
CVE-2026-2836
GHSA-f93w-pcj3-rggc
RUSTSEC-2026-0035
Mar 05, 2026
Pingora vulnerable to cache poisoning via insecure-by-default cache key
High
Network
Low
None
ImpactPingora versions prior to 0.8.0 generated cache keys using only the URI path, excluding critical factors such as the host header. This allows an attacker to poison the cache and serve cross-origin responses to users. This vulnerability affects users of Pingora's alpha proxy caching feature who relied on the default CacheKey implementation. An attacker could exploit this for cross-tenant data leakage in multi-tenant deployments, or serve malicious content to legitimate users by poisoning shared cache entries. Note: Cloudflare customers and Cloudflare's CDN infrastructure were not affected by this vulnerability, as Cloudflare's default cache key implementation uses multiple factors to prevent cache key poisoning and never made use of the previously provided default. PatchesWe strongly suggest users should upgrade to Pingora v.0.8.0 or higher, which removes the default CacheKey implementation. WorkaroundsDo not rely on the provided CacheKey default, and at minimum use the host / :authority and the upstream peer TLS scheme as part of building the CacheKey, as well as other factors that may apply to the deployment e.g. HTTP method. ReferencesSee CVE-2026-2836 and the Cloudflare blog post for more details. CreditsDisclosed responsibly by Rajat Raghav (@xclow3n) through the Cloudflare Bug Bounty Program. Fixed in
0.8.0
References Updated Mar 09, 2026 · Source: OSV.dev |