GHSA-hm8q-7f3q-5f36
Improper Input Validation vulnerability in hono (npm)

Improper Input Validation No known exploit

What is GHSA-hm8q-7f3q-5f36 About?

This vulnerability involves improper validation of JWT NumericDate claims (`exp`, `nbf`, `iat`) in `hono/utils/jwt`, allowing malformed values to bypass time-based checks. This can lead to tokens being treated as valid indefinitely or prematurely. Exploitation requires an attacker to control the signing key or be able to issue malformed tokens.

Affected Software

hono <4.12.18

Technical Details

The hono/utils/jwt library's validation routine for JWT NumericDate claims (exp, nbf, iat) combines option, presence, and threshold checks in a single short-circuiting expression. This design flaw causes several types of malformed claim values to be silently skipped instead of being correctly rejected. Specifically: (1) A falsy numeric value (e.g., 0) would short-circuit the presence check, effectively being ignored. (2) A non-finite numeric value (e.g., Infinity, -Infinity) would result in comparisons that evaluate as never-after-now or never-expired, thus bypassing the intended time checks. (3) A non-numeric type (e.g., a string or object) would lead to NaN comparisons, which always evaluate to false, again bypassing the time checks. This behavior deviates from RFC 7519 §4.1.4, which mandates that NumericDate claims must be finite JSON numeric values. Consequently, tokens with improperly formatted time claims can bypass configured temporal validity constraints.

What is the Impact of GHSA-hm8q-7f3q-5f36?

Successful exploitation may allow attackers to craft JWT tokens that are perpetually valid, or whose `nbf` and `iat` claims are accepted despite being in the future. This can bypass time-based access controls and lead to unauthorized access or manipulation of features.

What is the Exploitability of GHSA-hm8q-7f3q-5f36?

Exploitation of this vulnerability is not possible by an anonymous attacker; it requires the ability to issue tokens accepted by the application. This typically means the attacker either controls the JWT signing key or has an avenue to inject malformed claims into tokens legitimately issued by the application. The complexity of exploiting this is moderate, as it requires understanding JWT claim specifications and how the hono/utils/jwt library validates them. No direct authentication is required for the exploit itself, but the prerequisite of issuing tokens implies prior access or control over a token issuance mechanism. Privilege requirements depend on how an attacker can manipulate token issuance. The attack is remote, as it involves submitting a crafted JWT. The primary constraint is controlling the signing key or the token issuance process. Deployments using a well-formed token issuer and protecting the signing key are not affected, making this a vulnerability primarily when internal processes misconfigure or attackers compromise the token issuance.

What are the Known Public Exploits?

PoC Author Link Commentary
No known exploits

What are the Available Fixes for GHSA-hm8q-7f3q-5f36?

Available Upgrade Options

  • hono
    • <4.12.18 → Upgrade to 4.12.18

Struggling with dependency upgrades?

See how Resolved Security's drop-in replacements make it simple.

Book a demo

Additional Resources

What are Similar Vulnerabilities to GHSA-hm8q-7f3q-5f36?

Similar Vulnerabilities: CVE-2022-25925 , CVE-2021-39148 , CVE-2021-27956 , CVE-2020-28283 , CVE-2019-1000008