Integer Overflow in Axum with Jwt Tokens

Integer overflow in Axum when processing JWT tokens occurs when arithmetic on token-related numeric claims (commonly exp, nbf, iat, or custom numeric payload fields) exceeds the safe range of the chosen integer type. In Rust, the default integer types such as u32 or u64 have fixed bounds; wrapping behavior in release builds means a value that grows beyond the maximum silently wraps to a small number, which can cause validation logic to accept tokens that appear not yet valid or not yet expired.

Consider an Axum extractor that parses a JWT and checks exp using a u32 field in a claims struct. If an attacker supplies a crafted token with a very large exp (for example, a value near u32::MAX), the subtraction exp - current_time can wrap around to a small unsigned number, making the token seem valid for a long period or even always valid depending on how the comparison is written. This is effectively an authentication bypass rooted in unchecked arithmetic rather than a cryptographic weakness in the JWT library itself.

In a black-box scan, middleBrick tests such edge cases as part of its Input Validation checks and maps findings to relevant OWASP API Top 10 categories. Because JWTs often carry time-sensitive claims, integer overflow can distort authorization decisions and undermine the intended validity window. The presence of overflow-prone code is especially risky when combined with other unchecked deserialization paths or when numeric claims are used to compute access scopes or rate-limit windows.

To detect this pattern, a scanner compares the deserialized claim types in the OpenAPI schema (if available) with the runtime values observed in test payloads. If the schema defines a field as u32 but runtime tests send very large integers, the mismatch is flagged as a potential input validation issue. The scanner does not alter application code; it highlights where arithmetic on token metadata should be hardened to avoid overflow-based logic errors.

Remediation focuses on using safe arithmetic and robust claim validation in Axum extractors. Prefer signed 64-bit integers (i64) for Unix timestamp claims such as exp and nbf, and validate ranges before using them in comparisons. Explicitly check that timestamps are within acceptable bounds relative to the current time, and avoid wrapping subtraction by validating non-negative deltas carefully.

Example of a vulnerable extractor before fix:

// Vulnerable: uses u32 for exp, susceptible to wrap
#[derive(serde::Deserialize)]
struct Claims {
    sub: String,
    exp: u32,
    iat: u32,
}

async fn validate_jwt(
    token: String,
) -> Result {
    let key = DecodingKey::from_secret("secret".as_ref());
    let token_data = decode::(
        &token,
        &key,
        &Validation::new(Algorithm::HS256),
    )?;
    let now = current_time_seconds(); // u32 helper
    if now < token_data.claims.nbf {
        return Err("token not yet valid");
    }
    if token_data.claims.exp < now {
        return Err("token expired");
    }
    Ok(token_data.claims)
}

The above code risks integer wrap in both nbf and exp if the runtime values or the helper current_time_seconds overflow. A safer approach uses i64 for timestamps and explicit range checks:

Fixed extractor example:

// Safer: use i64 and validate ranges
#[derive(serde::Deserialize)]
struct Claims {
    sub: String,
    exp: i64,
    nbf: i64,
    iat: i64,
}

async fn validate_jwt(
    token: String,
) -> Result<Claims, &str> {
    use std::time::{SystemTime, UNIX_EPOCH};
    let key = DecodingKey::from_secret("secret".as_ref());
    let token_data = decode::(
        &token,
        &key,
        &Validation::new(Algorithm::HS256),
    )?;
    let now = SystemTime::now()
        .duration_since(UNIX_EPOCH)
        .map_err(|_| "time error")?
        .as_secs() as i64;
    // Ensure non-negative deltas without relying on wrapping subtraction
    if now < token_data.claims.nbf {
        return Err("token not yet valid");
    }
    if token_data.claims.exp < now {
        return Err("token expired");
    }
    // Optionally enforce a maximum lifetime window
    const MAX_LIFETIME: i64 = 3600; // 1 hour
    if now - token_data.claims.iat > MAX_LIFETIME {
        return Err("token too old since issuance");
    }
    Ok(token_data.claims)
}

Additional hardening steps include validating the numeric ranges of custom claims, using well-audited JWT libraries, and ensuring that any deserialization into structs aligns with the expected JSON numeric types. In a middleBrick scan, these practices reduce the likelihood of findings related to Input Validation and Authentication, and they complement the continuous monitoring and CI/CD integration options available in the Pro plan for repeated assurance as code evolves.

middleBrick scans Axum endpoints that expose JWT-based authentication, testing unauthenticated attack surfaces where integer overflow may distort authorization. The scanner cross-references OpenAPI/Swagger specs (including $ref resolution) with runtime payloads to surface mismatches in expected numeric ranges. Findings are mapped to frameworks such as OWASP API Top 10 and can align with compliance requirements including PCI-DSS and SOC2 when relevant controls are in scope.

For teams with active pipelines, the GitHub Action can add API security checks to CI/CD and fail builds if risk scores fall below chosen thresholds. The CLI allows on-demand scans from the terminal:

middlebrick scan https://api.example.com/openapi.json

Organizations needing continuous monitoring across many Axum services or requiring detailed compliance reports may consider the Pro plan, which supports configurable scan schedules and richer alerting. The scanner provides detection and reporting with remediation guidance, but does not modify code, block traffic, or patch systems.