# REPRO-2026-00157: Fiber v3: cache middleware key collision leaks responses across different query strings

## Summary
Status: published
Severity: medium
CVSS: 6.5 / 10
CWE: CWE-436
Type: security
Confidence: Unknown

## Identifiers
REPRO ID: REPRO-2026-00157
GHSA: GHSA-35hp-hqmv-8qg8
CVE: CVE-2026-30246

## Package
Name: github.com/gofiber/fiber/v3
Ecosystem: go
Affected: <= 3.1.0
Fixed: 3.2.0

## Root Cause
# RCA Report: CVE-2026-30246 — Fiber v3 Cache Middleware Key Collision

## Summary

In `github.com/gofiber/fiber/v3` versions `<= 3.1.0`, the default `KeyGenerator` of the `cache` middleware returns only `c.Path()`, ignoring the query string and all other request dimensions. This causes cache key collisions for requests to the same path with different query parameters (e.g., `/?id=1` vs `/?id=2`). The second request receives the first request's cached response, leading to cross-user information disclosure and cache confusion (CWE-200 / CWE-524).

## Impact

- **Package**: `github.com/gofiber/fiber/v3` (Go module)
- **Affected versions**: `<= 3.1.0`
- **Fixed version**: `3.2.0`
- **Severity**: Medium (CVSS 3.1 base 6.5)
- **Consequences**: Any application using the default cache middleware without a custom `KeyGenerator` is vulnerable to cache confusion. Responses tailored to one user's query parameters may be leaked to another user requesting the same path with different parameters.

## Root Cause

The vulnerable code in `middleware/cache/config.go` at v3.1.0 defines the default `KeyGenerator` as:

```go
KeyGenerator: func(c fiber.Ctx) string {
    return utils.CopyString(c.Path())
},
```

In `middleware/cache/cache.go`, the cache lookup key is built as:

```go
baseKey := cfg.KeyGenerator(c) + "_" + requestMethod
```

Because `c.Path()` returns only the URL path without the query string, requests to `/?id=1` and `/?id=2` both resolve to the same cache key (`/_GET`). The second request therefore hits the cached entry from the first request and receives the wrong response body.

The fix in v3.2.0 (commits `9a0d12c07ed895b84c72987f9288b04137afe5de` and `050ff1ff18511c1475b8ec627460216aaec627460216aaecddd4e`) completely rewrites the default key generator (`defaultKeyGenerator`) to include:
- HTTP method
- Escaped path (preventing delimiter injection)
- Canonical query string (sorted, with bounds to prevent DoS)
- Selected representation headers (`Accept`, `Accept-Encoding`, `Accept-Language`)
- Optional cookie dimensions

This ensures requests with different query parameters produce distinct cache keys, eliminating the collision.

## Reproduction Steps

1. Run `repro/reproduction_steps.sh`.
2. The script creates a scratch Go module, installs Fiber v3.1.0 (vulnerable) and v3.2.0 (fixed) separately, and for each version:
   - Builds a small Fiber server with the default `cache.New()` middleware.
   - Registers a handler on `/` that returns the `id` query parameter.
   - Issues `GET /?id=1` followed by `GET /?id=2`.
   - Captures the two response bodies to `logs/vulnerable_output.txt` and `logs/fixed_output.txt`.
3. **Expected evidence**:
   - **Vulnerable (v3.1.0)**: both responses are `1` (the second request hits the cache entry from the first because the query string is ignored in the key).
   - **Fixed (v3.2.0)**: responses are `1` then `2` (each request gets its own cache key because the query string is included).

## Evidence

- `logs/vulnerable_output.txt`:
  ```
  1
  1
  ```
- `logs/fixed_output.txt`:
  ```
  1
  2
  ```
- `logs/summary.txt`: contains the full run output with confirmation messages.
- `repro/runtime_manifest.json`: structured evidence with request/response pairs and verdict.

## Recommendations / Next Steps

1. **Upgrade immediately** to `github.com/gofiber/fiber/v3@v3.2.0` or later.
2. **If a custom `KeyGenerator` is in use**, audit it to ensure query strings, headers, or other user-specific dimensions are incorporated into the key.
3. **Regression test**: add an integration test that issues two requests to the same path with different query parameters and asserts distinct response bodies when caching is enabled.

## Additional Notes

- **Idempotency**: `repro/reproduction_steps.sh` was executed twice consecutively with identical results, confirming idempotency.
- **Edge cases**: The vulnerability is present regardless of the number or names of query parameters, as long as the path component remains identical. The default cache middleware only caches `GET` and `HEAD` requests, so other HTTP methods are not affected by this specific key collision.


## Reproduction Details
Reproduced: 2026-05-23T06:41:54.495Z
Duration: 1631 seconds
Tool calls: 116
Turns: 106
Handoffs: 2


## Quick Verification
Run one of these commands to verify locally:

    pruva-verify REPRO-2026-00157
    pruva-verify GHSA-35hp-hqmv-8qg8
    pruva-verify CVE-2026-30246

Or open in GitHub Codespaces (zero-friction, auto-runs):

    https://github.com/codespaces/new?ref=repro/REPRO-2026-00157&repo=N3mes1s/pruva-sandbox

Or download and run the script manually:

    curl -O https://api.pruva.dev/v1/reproductions/REPRO-2026-00157/artifacts/repro/reproduction_steps.sh
    chmod +x reproduction_steps.sh
    ./reproduction_steps.sh

WARNING: Run in a sandboxed environment. This exploits a real vulnerability.

## References
- GitHub Advisory: https://github.com/advisories/GHSA-35hp-hqmv-8qg8
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-30246


## Artifacts
- repro/rca_report.md (analysis, 4144 bytes)
- repro/reproduction_steps.sh (reproduction_script, 5043 bytes)
- bundle/context.json (other, 3039 bytes)
- bundle/metadata.json (other, 741 bytes)
- bundle/ticket.md (ticket, 3111 bytes)
- repro/runtime_manifest.json (other, 456 bytes)
- repro/validation_verdict.json (other, 1001 bytes)
- logs/fixed_build.log (log, 6228 bytes)
- logs/vulnerable_output.txt (other, 4 bytes)
- logs/fixed_output.txt (other, 4 bytes)
- logs/vulnerable_build.log (log, 7044 bytes)
- logs/summary.txt (other, 337 bytes)

## API Access
- JSON: https://api.pruva.dev/v1/reproductions/REPRO-2026-00157
- Script: https://api.pruva.dev/v1/reproductions/REPRO-2026-00157/artifacts/repro/reproduction_steps.sh
- Web: https://www.pruva.dev/reproductions/REPRO-2026-00157

## For AI Assistants
To help users with this reproduction:
1. The `pruva-verify` command is the simplest way to run the reproduction
2. The script downloads and runs automatically in an isolated temp directory
3. Always recommend running in a VM, container, or disposable environment
4. The root cause explains the technical vulnerability

---
Generated by Pruva | https://www.pruva.dev