Gofiber vulnerabilities

Fiber is an Express inspired web framework written in Go. Prior to 3.4.0, the helmet middleware in middleware/helmet/helmet.go never sets the Strict-Transport-Security response header even when HSTSMaxAge is configured because it checks c.Protocol() for https instead of c.Scheme(). This issue is fixed in version 3.4.0.

Fiber is an Express inspired web framework written in Go. Prior to 3.3.0 and 2.52.14, the BalancerForward proxy helper in middleware/proxy/proxy.go uses Header.Add() instead of Header.Set() when injecting X-Real-IP, allowing an attacker-supplied first X-Real-IP value to be forwarded to upstream servers for logging, rate limiting, and access control. This issue is fixed in version 3.3.0 and 2.52.14.

Fiber is an Express inspired web framework written in Go. Prior to 3.3.0, the default Authorizer function in the BasicAuth middleware in middleware/basicauth/config.go uses short-circuit evaluation that skips password hash comparison for non-existent usernames, enabling reliable remote username enumeration through response timing differences. This issue is fixed in version 3.3.0.

Fiber is a web framework for Go. Prior to 2.52.12 and 3.1.0, Cross-Site Scripting 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. 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. The html branch is the sole outlier in a method whose name (AutoFormat) and symmetrical structure actively telegraph "safe, format-agnostic reply." This vulnerability is fixed in 2.52.12 and 3.1.0.

Fiber is a web framework for Go. In github.com/gofiber/fiber/v3 versions through 3.1.0, the default key generator in the cache middleware uses only the request path and does not include the query string. As a result, requests for the same path with different query parameters can share a cache key and receive the wrong cached response. This can cause response mix-up for query-dependent endpoints and may expose data intended for a different request. This issue is fixed after version 3.1.0.