GHSA-35hp-hqmv-8qg8

Описание

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:

Reproduction:

1. GET /?id=1
   • Cache miss
   • Response body: 1
2. GET /?id=2
   • Cache hit
   • Response body: 1 (expected 2)

Local verification command used:

Observed 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.