This PR contains the following updates:

Package	Change	Age	Confidence
github.com/gofiber/fiber/v2	v2.49.1 -> v2.52.9
github.com/gofiber/fiber/v2	v2.52.4 -> v2.52.9

GitHub Vulnerability Alerts

CVE-2023-41338

Impact

This vulnerability can be categorized as a security misconfiguration. It impacts users of our project who rely on the 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():

// 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()

Patches

This issue has been patched in v2.49.2 with 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

CVE-2023-45128

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.

3. 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.

4. 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.

CVE-2023-45141

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.

3. 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.

4. 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.

CVE-2024-25124

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:

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
CodeQL on CORS Misconfiguration
PortSwigger on Exploiting CORS Misconfigurations
WhatWG CORS protocol and credentials

CVE-2024-38513

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

Users are encouraged to review these references and take immediate action to secure their applications.

CVE-2025-54801

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

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:

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:

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.

Release Notes

// Direct usage with default config
app.Use(healthcheck.New())

// Or extend your config for customization
app.Use(healthcheck.New(healthcheck.Config{
    LivenessEndpoint: "/live",
    LivenessProbe: func(c *fiber.Ctx) bool {
        return true
    },
    ReadinessEndpoint: "/ready",
    ReadinessProbe: func(c *fiber.Ctx) bool {
        return serviceA.Ready() && serviceB.Ready() && ...
    },
}))

// Consideration of parameters in the accepted headers
// Accept: text/plain, application/json; version=1; foo=bar

app.Get("/", func(c *fiber.Ctx) error {
  // Extra parameters in the accept are ignored
  c.Accepts("text/plain;format=flowed") // "text/plain;format=flowed"

  // An offer must contain all parameters present in the Accept type
  c.Accepts("application/json") // ""

  // Parameter order and capitalization does not matter. Quotes on values are stripped.
  c.Accepts(`application/json;foo="bar";VERSION=1`) // "application/json;foo="bar";VERSION=1"
})

// Passing a custom json type
ctx.JSON(fiber.Map{
    "type": "https://example.com/probs/out-of-credit",
    "title": "You do not have enough credit.",
    "status": 403,
    "detail": "Your current balance is 30, but that costs 50.",
    "instance": "/account/12345/msgs/abc",
  }, fiber.)

- func (c *Ctx) GetReqHeaders() map[string]string
+ func (c *Ctx) GetReqHeaders() map[string][]string

- func (c *Ctx) GetRespHeaders() map[string]string
+ func (c *Ctx) GetRespHeaders() map[string][]string

// Field names should start with an uppercase letter
type Person struct {
    Name     string  `cookie:"name"`
    Age      int     `cookie:"age"`
    Job      bool    `cookie:"job"`
}
// Example route
app.Get("/", func(c *fiber.Ctx) error {
    p := new(Person)
    // This method is similar to BodyParser, but for cookie parameters
    if err := c.CookieParser(p); err != nil {
        return err
    }
    
    log.Println(p.Name)     // Joseph
    log.Println(p.Age)      // 23
    log.Println(p.Job)      // true
})

// To disable caching completely, pass MaxAge value negative. It will set the Access-Control-Max-Age header 0.
app.Use(cors.New(cors.Config{MaxAge: -1})) 

// Provide more flexibility in session management, especially in scenarios like repeated user logins
func (s *Session) Reset() error

// Initialize default config
// This stores all of your app's sessions
store := session.New()

app.Post("/login", func(c *fiber.Ctx) error {
    // Get session from storage
    sess, err := store.Get(c)
    if err != nil {
        panic(err)
    }
    
    // ... validate login ...
    
    // Check if the session is fresh
    if !sess.Fresh() {
        // If the session is not fresh, reset it
        if err := sess.Reset(); err != nil {
            panic(err)
        }
    }
    // Set new session data
    sess.Set("user_id", user.ID)
    // Save session
    if err := sess.Save(); err != nil {
        panic(err)
    }

    return c.SendString(fmt.Sprintf("Welcome %v", user.ID))
})

// Provide more control over individual session management, especially in scenarios 
// like administrator-enforced user logout or user-initiated logout from a specific device session
func (s *Store) Delete(id string) error

app.Post("/admin/session/:id/logout", func(c *fiber.Ctx) error {
    // Get session id from request
    sessionID := c.Params("id")

    // Delete the session
    if err := store.Delete(sessionID); err != nil {
        return c.Status(500).SendString(err.Error())
    }

    return c.SendString("Logout successful")
})

Configuration

📅 Schedule: Branch creation - "" (UTC), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about these updates again.

• If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.