Integer Overflow in Fiber with Jwt Tokens

An integer overflow in a Fiber-based API that processes JWT tokens can occur when user-controlled numeric claims (such as exp, nbf, or custom numeric payload fields) are parsed into fixed-size integer types without range validation. In Go, if a claim value is decoded into an int or int32 and the attacker supplies a very large number (e.g., 9223372036854775807 for int64 max), intermediate arithmetic (such as adding timestamps or computing expiration deltas) can wrap around, producing a small resulting value. This may cause the token to be treated as not yet expired or as valid far into the future, bypassing intended validity checks.

Because JWT tokens are often parsed before authorization decisions, an overflow in timestamp or numeric claim handling can weaken time-bound protections that rely on correct integer arithmetic. For example, computing now + leeway where leeway comes from the token may overflow and become negative or very small, leading to incorrect acceptance of expired tokens. In Fiber, this risk is relevant when custom middleware or claim validation logic performs arithmetic on decoded numeric fields without checking for overflow or using safe parsing (e.g., using math/bits or big integers).

Consider a scenario where a token contains a custom claim session_max_seconds supplied by an attacker. If the server decodes this into an int and adds it to the current Unix timestamp to compute an allowed window, an overflow can produce a timestamp in the past or an incorrect far-future time. Because the token is trusted after parsing, the server may grant extended access unintentionally. MiddleBrick scans detect such insecure handling of numeric claims in JWT processing paths and highlight them alongside broader API security checks.

Real-world attack patterns mirror known issues like CVE-2020-26160 (JWT alg confusion) and implementation-level integer bugs that arise from unchecked numeric inputs. While the vulnerability resides in the application’s handling of decoded claims rather than the JWT library itself, the presence of JWT tokens amplifies impact by allowing an authenticated token to be manipulated into extended validity or elevated logical state. Using middleware that validates and sanitizes numeric claims before arithmetic is essential.

To remediate integer overflow risks when handling JWT tokens in Fiber, validate and safely parse all numeric claims before performing arithmetic. Use 64-bit unsigned integers where appropriate and check for overflow before addition or comparison. Below are concrete code examples that demonstrate secure handling in a Fiber handler.

Example 1: Safe parsing and validation of a numeric claim before computing an expiration window.

package main

import (
	"errors"
	"math"
	"net/http"
	"strconv"

	"github.com/gofiber/fiber/v2"
	"github.com/golang-jwt/jwt/v5"
)

type CustomClaims struct {
	SessionMaxSeconds uint64 `json:"session_max_seconds"`
	jwt.RegisteredClaims
}

func safeAddUint64(a, b uint64) (uint64, error) {
	if b > math.MaxUint64-a {
		return 0, errors.New("overflow")
	}
	return a + b, nil
}

func handler(c *fiber.Ctx) error {
	tokenString := c.Get("Authorization")
	if len(tokenString) <= 7 {
		return c.Status(http.StatusUnauthorized).JSON(fiber.Map{"error": "invalid token"})
	}
	tokenString = tokenString[7:] // strip Bearer
	token, _, err := new(jwt.Parser).ParseUnverified(tokenString, &CustomClaims{})
	if err != nil {
		return c.Status(http.StatusBadRequest).JSON(fiber.Map{"error": "invalid token"})
	}

	claims, ok := token.Claims.(*CustomClaims)
	if !ok || !token.Valid {
		return c.Status(http.StatusBadRequest).JSON(fiber.Map{"error": "invalid claims"})
	}

	now := uint64(time.Now().Unix())
	allowedEnd, err := safeAddUint64(now, claims.SessionMaxSeconds)
	if err != nil {
		return c.Status(http.StatusBadRequest).JSON(fiber.Map{"error": "invalid session max seconds"})
	}

	exp := uint64(claims.ExpiresAt.Time.Unix())
	if exp > allowedEnd {
		return c.Status(http.StatusForbidden).JSON(fiber.Map{"error": "token expired by policy"})
	}

	c.Locals("user", claims.Subject)
	return c.Next()
}

Example 2: Using middleware to enforce numeric bounds and reject tokens with suspicious claim values.

func ValidateNumericClaims() fiber.Handler {
	return func(c *fiber.Ctx) error {
		tokenString := c.Get("Authorization")
		if len(tokenString) <= 7 {
			return c.Next()
		}
		tokenString = tokenString[7:]
		token, _, err := new(jwt.Parser).ParseUnverified(tokenString, &CustomClaims{})
		if err != nil {
			return c.Next()
		}
		if claims, ok := token.Claims.(*CustomClaims); ok && token.Valid {
			// Reject obviously out-of-range values that may indicate overflow manipulation
			if claims.SessionMaxSeconds > 31536000*2 { // e.g., more than 2 years in seconds
				return c.Status(http.StatusBadRequest).JSON(fiber.Map{"error": "claim value out of range"})
			}
			c.Locals("sessionMax", claims.SessionMaxSeconds)
		}
		return c.Next()
	}
}

In addition to code fixes, adopt operational practices such as continuous monitoring of API security scores. The middleBrick CLI can be used in scripts to scan endpoints and surface JWT-related findings. For teams seeking deeper integration, the middleBrick GitHub Action can add API security checks to your CI/CD pipeline, failing builds if risk scores drop below a chosen threshold. The middleBrick MCP Server allows AI coding assistants to trigger scans directly from the IDE, helping catch issues early.