Skip to main content

Fiber Cache Middleware EUVDEUVD-2026-27313

| CVE-2026-30246 MEDIUM
Information Exposure (CWE-200)
2026-04-28 https://github.com/gofiber/fiber GHSA-35hp-hqmv-8qg8
6.5
CVSS 3.1 · GitHub Advisory
Share

Severity by source

GitHub Advisory PRIMARY
6.5 MEDIUM
AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
vuln.today AI
6.5 MEDIUM

Network-accessible HTTP exploit requiring no credentials; limited confidentiality and integrity impact from cross-user cache contamination; no availability effect.

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
4.0 AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N
SUSE
MEDIUM
qualitative

Primary rating from GitHub Advisory.

CVSS VectorGitHub Advisory

Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
Low
Integrity
Low
Availability
None

Lifecycle Timeline

4
Source Code Evidence Fetched
Jul 24, 2026 - 04:00 vuln.today
Analysis Generated
Jul 24, 2026 - 04:00 vuln.today
Patch released
Apr 28, 2026 - 22:30 nvd
Patch available
CVE Published
Apr 28, 2026 - 22:28 nvd
MEDIUM 6.5

DescriptionGitHub 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:

go
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:

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

Local verification command used:

bash
go test ./middleware/cache -run Test_Cache_WithNoCacheRequestDirective -count=1

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.

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.

Vendor StatusVendor

SUSE

Severity: Moderate
Product Status
SUSE Linux Enterprise Server 16.1 Affected
SUSE Linux Enterprise Server for SAP applications 16.1 Affected

Share

EUVD-2026-27313 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy