Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
Network-accessible HTTP exploit requiring no credentials; limited confidentiality and integrity impact from cross-user cache contamination; no availability effect.
Primary rating from GitHub Advisory.
CVSS VectorGitHub Advisory
Lifecycle Timeline
4DescriptionGitHub Advisory
Summary
Fiber cache middleware's default key generator uses only c.Path() and does not include the query string. As a result, requests like /?id=1 and /?id=2 can map to the same cache key and share the same cached response.
This can cause response mix-up (cache poisoning-like behavior) for endpoints where response content depends on query parameters.
Details
Default configuration in cache middleware:
KeyGenerator: func(c fiber.Ctx) string { return utils.CopyString(c.Path()) }
References:
- https://github.com/gofiber/fiber/blob/main/middleware/cache/config.go#L90-L92
- https://github.com/gofiber/fiber/blob/main/middleware/cache/cache_test.go#L599-L621
The existing test demonstrates that when handler output depends on query parameter id, a second request with a different query still returns the first cached response (cache hit), confirming query is not part of the default cache key.
PoC
Minimal PoC:
package main
import (
"log"
"github.com/gofiber/fiber/v3"
"github.com/gofiber/fiber/v3/middleware/cache"
)
func main() {
app := fiber.New()
app.Use(cache.New()) // default config
app.Get("/", func(c fiber.Ctx) error {
return c.SendString(c.Query("id", "1"))
})
log.Fatal(app.Listen(":3000"))
}Reproduction:
GET /?id=1
- Cache miss
- Response body:
1
GET /?id=2
- Cache hit
- Response body:
1(expected2)
Local verification command used:
go test ./middleware/cache -run Test_Cache_WithNoCacheRequestDirective -count=1Observed result: test passes, confirming this is current behavior.
Impact
- Responses that should vary by query parameters can be mixed between requests.
- In real deployments, this may leak or corrupt user/tenant-specific content if query parameters influence context or data selection.
- This is deployment-dependent but security-relevant, and not safe-by-default for query-variant responses.
Suggested remediation
- Change default cache key generation to include path + normalized query string (or canonicalized original URL).
- Keep ability for custom key generators.
- Add explicit documentation warning that path-only keying is unsafe for query-dependent responses.
AnalysisAI
Fiber v3 cache middleware's default KeyGenerator discards the query string entirely, keying responses solely on the request path, which causes requests to distinct URIs such as /?id=1 and /?id=2 to share a single cache slot. Any network-accessible application using default configuration on query-variant endpoints will serve the first cached response to all subsequent callers regardless of their query parameters, creating a cache poisoning-like information disclosure and integrity corruption scenario. A working proof-of-concept is embedded in the GHSA advisory and an existing test case in the repository confirms the behavior; SSVC rates exploitation as automatable, though EPSS remains very low at 0.03% with no CISA KEV listing, indicating no observed mass exploitation as of analysis time.
Technical ContextAI
Fiber (GoFiber) is a high-performance Go web framework built on FastHTTP. Its cache middleware (pkg:go/github.com/gofiber/fiber/v3) provides HTTP response caching governed by a configurable KeyGenerator function. The default KeyGenerator, defined in middleware/cache/config.go lines 90-92, is func(c fiber.Ctx) string { return utils.CopyString(c.Path()) }, which silently discards query parameters. CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor) applies: when application handlers return different content based on query parameters - such as user IDs, tenant identifiers, or filter values - the path-only cache key conflates logically distinct requests into a single cache entry, causing the first cached response to be served to all subsequent callers on the same path. The patch commits (050ff1ff and 9a0d12c0) update the canonicalQueryString helper to wrap query segments with escapeKeyDelimiters(), ensuring query string data is incorporated into cache keys without delimiter collision, and also fix a Methods slice mutation bug in configDefault.
RemediationAI
Upgrade to Fiber v3.2.0 or later, which resolves the issue via patch commits 050ff1ff18511c1475b8ec627460216aaecddd4e and 9a0d12c07ed895b84c72987f9288b04137afe5de; the authoritative advisory is at https://github.com/gofiber/fiber/security/advisories/GHSA-35hp-hqmv-8qg8. If an immediate upgrade is not feasible, override the default KeyGenerator in your cache middleware configuration to include the full query string - for example: cache.New(cache.Config{KeyGenerator: func(c fiber.Ctx) string { return c.Path() + "?" + string(c.Request().URI().QueryArgs().QueryString()) }}). This workaround correctly differentiates cache entries by query string but will increase cache miss rates since previously conflated entries become distinct slots. For high-sensitivity endpoints (user-specific or tenant-specific data) where any cross-contamination is unacceptable, disabling the cache middleware selectively on those routes is the safest interim control with the trade-off of losing caching performance benefits.
Same weakness CWE-200 – Information Exposure
View allSame technique Information Disclosure
View allVendor StatusVendor
SUSE
Severity: Moderate| Product | Status |
|---|---|
| SUSE Linux Enterprise Server 16.1 | Affected |
| SUSE Linux Enterprise Server for SAP applications 16.1 | Affected |
Share
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-27313
GHSA-35hp-hqmv-8qg8