Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
7 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
The BalancerForward proxy helper in GoFiber uses Header.Add() instead of Header.Set() when injecting the X-Real-IP header. This appends the real client IP as a second header value rather than replacing any attacker-supplied value. Upstream servers that read the first X-Real-IP header (nginx, Express, most HTTP servers) use the attacker's spoofed IP for logging, rate limiting, and access control. Vulnerable Code File: middleware/proxy/proxy.go, lines 270-285 Data Flow 1. Attacker sends request with X-Real-IP: 10.0.0.1 (spoofed internal IP) 2. BalancerForward handler executes at line 282 3. c.Request().Header.Add("X-Real-IP", c.IP()) APPENDS the real IP as a second header 4. Upstream server receives: X-Real-IP: 10.0.0.1 AND X-Real-IP: <real-attacker-ip 5. Most HTTP servers (nginx, Node.js, Apache) read the FIRST value 6. Upstream uses 10.0.0.1 for all IP-dependent logic Impact - Rate limit bypass: IP-based rate limiting at the upstream uses the spoofed IP, allowing unlimited…
Recommended action: Upgrade to 3.3.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The default Authorizer function in GoFiber's BasicAuth middleware uses short-circuit evaluation that skips password hash comparison for non-existent usernames. With bcrypt-hashed passwords (the primary use case), the timing difference between a valid and invalid username is approximately 1,000,000:1 (~100ms vs ~100ns), enabling reliable remote username enumeration. Vulnerable Code File: middleware/basicauth/config.go, lines 126-138 Data Flow 1. Attacker sends Authorization: Basic <base64(candidate:wrongpass) 2. BasicAuth middleware decodes credentials and calls cfg.Authorizer(user, pass, c) 3. Map lookup verifiers[user] returns ok=false for non-existent users 4. Go && short-circuit: false && verify(pass) returns immediately without calling verify() 5. For valid users, verify(pass) executes bcrypt.CompareHashAndPassword() (line 167: ~100ms at default cost 10) 6. Timing difference: ~100ns (invalid user) vs ~100ms (valid user) = 1,000,000:1 ratio Timing comparison by hash type:…
Recommended action: Upgrade to 3.3.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Description A Cross-Site Scripting (CWE-79) vulnerability in Go Fiber allows a remote attacker to inject arbitrary HTML/JavaScript by supplying Accept: text/html on any request whose handler passes attacker-influenced data to the AutoFormat() feature. This affects github.com/gofiber/fiber/v3 (DefaultRes.AutoFormat) through version 3.1.0 and github.com/gofiber/fiber/v2 (Ctx.Format) through version 2.52.12. The developer opts into content negotiation by calling AutoFormat(), but does not opt into raw HTML emission for a particular request; Fiber chooses that branch from attacker-controlled Accept. Five of the six branches of the same method already escape. JSON, XML, MsgPack, and CBOR all route through encoders that neutralize markup; the txt branch emits text/plain and cannot execute. The html branch is the sole outlier in a method whose name (AutoFormat) and symmetrical structure actively telegraph "safe, format-agnostic reply." Details The issue resides in res.go within…
Recommended action: Upgrade to 3.2.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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/cachetest.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…
Recommended action: Upgrade to 3.2.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A denial of service vulnerability exists in Fiber v2 and v3 that allows remote attackers to crash the application by sending requests to routes with more than 30 parameters. The vulnerability results from missing validation during route registration combined with an unbounded array write during request matching. Affected Versions - Fiber v3.0.0-rc.3 and earlier v3 releases - Fiber v2.52.10 and potentially all v2 releases (confirmed exploitable) - Both versions share the same vulnerable routing implementation Vulnerability Details Root Cause Both Fiber v2 and v3 define a fixed-size parameter array in ctx.go: The router.go register() function accepts routes without validating parameter count. When a request matches a route exceeding 30 parameters, the code in path.go performs an unbounded write: - v3: path.go:514 - v2: path.go:516 When paramsIterator = 30, this triggers: Attack Scenario 1. Application registers route with 30 parameters (e.g., via code or dynamic routing): 2. Attacker…
Recommended action: Upgrade to 3.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The use of the fiberflash cookie can force an unbounded allocation on any server. A crafted 10-character cookie value triggers an attempt to allocate up to 85GB of memory via unvalidated msgpack deserialization. No authentication is required. Every GoFiber v3 endpoint is affected regardless of whether the application uses flash messages. Details Regardless of configuration, the flash cookie is checked: The cookie value is hex-decoded and passed directly to msgpack deserialization with no size or content validation: https://github.com/gofiber/fiber/blob/f8f34f642fb3682c341ede7816e7cf861aa7df89/redirect.go#L371 The auto-generated tinylib/msgp deserialization reads a uint32 array header from the attacker-controlled byte stream and passes it directly to make() with no bounds check: https://github.com/gofiber/fiber/blob/f8f34f642fb3682c341ede7816e7cf861aa7df89/redirectmsgp.go#L242 where zb0002, bts, err = msgp.ReadArrayHeaderBytes(bts) translates the attacker-controlled value into…
Recommended action: Upgrade to 3.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Description A Path Traversal (CWE-22) vulnerability in Fiber allows a remote attacker to bypass the static middleware sanitizer and read arbitrary files on the server file system on Windows. This affects Fiber v3 through version 3.0.0. This has been patched in Fiber v3 version 3.1.0. Details The vulnerability resides in middleware/static/static.go within the sanitizePath function. This function attempts to sanitize the requested path by checking for backslashes, decoding the URL, and then cleaning the path. The vulnerability stems from two combined issues: - The check for backslash characters happens before the URL decoding loop. If an attacker sends a double-encoded backslash, the initial check sees %255C and passes. The loop then decodes this into a single backslash. - The function uses path.Clean to clean the resulting string. path.Clean is designed for slash-separated paths and does not recognize backslashes as directory separators. Consequently, sequences like ..\..\ are…
Recommended action: Upgrade to 3.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.