CVE-2026-44459

What it actually does

In Hono versions prior to 4.12.18, the JWT verification utility improperly validates the NumericDate claims `exp`, `nbf`, and `iat`. If a JWT contains malformed or non-spec-compliant values for these time-based claims, `verify()` may silently fail to enforce expiration, not-before, or issued-at checks as intended. The practical impact is limited because exploitation requires a malformed token to reach verification and generally requires the application to issue such a token itself or for an attacker to control or obtain the JWT signing key. This can weaken authentication or authorization logic that relies on JWT time validity, potentially allowing acceptance of tokens that should be considered expired, not yet valid, or otherwise invalid.

Why it matters to the business

Applications using affected Hono JWT functionality may accept invalid session or authorization tokens under specific conditions, which could result in unauthorized access or persistence beyond intended token lifetimes. The risk is constrained because anonymous attackers normally cannot exploit this without token-signing capability or an application workflow that generates malformed tokens. There is no known exploitation, it is not in CISA KEV, it is not associated with ransomware activity, and the EPSS score is low, so remediation should be prioritized as a routine security update rather than an emergency unless the application relies heavily on Hono JWT verification for sensitive access control.

How an attack unfolds

An attacker must cause a JWT with malformed `exp`, `nbf`, or `iat` claim values to be processed by Hono's `verify()` function. In the most realistic scenario, this occurs when an application itself issues tokens with non-compliant NumericDate values due to a coding or serialization defect. A more serious but less common scenario is where an attacker has access to the signing key or otherwise controls token generation, allowing them to craft a signed JWT with abnormal time-based claims. The vulnerable verification logic may then treat the malformed claims in a way that bypasses expected expiration, not-before, or issued-at enforcement. If the application trusts the verified token for authentication or authorization, the attacker may retain access longer than intended or use a token outside its intended validity window.

How to fix it

Upgrade Hono to version 4.12.18 or later wherever `hono/utils/jwt` is used. Because the provided fixed version information identifies 4.12.18 as the corrected release, pin dependencies to `hono@4.12.18` or a newer trusted version and rebuild/redeploy affected applications. Review direct and transitive dependency manifests, lockfiles, container images, serverless bundles, and edge runtime deployments to ensure no vulnerable Hono package remains in use. As defense in depth, validate JWT claim types before signing and after decoding: `exp`, `nbf`, and `iat` should be integers representing seconds since the Unix epoch, and tokens with missing, non-numeric, fractional, string, object, array, `NaN`, or infinite values should be rejected. Rotate JWT signing keys if there is any indication that token-signing material was exposed or that attackers could have generated signed tokens.

How to confirm the fix worked

Confirm that all deployed application artifacts use Hono 4.12.18 or later by checking `package.json`, package manager lockfiles, software bills of materials, deployed build artifacts, and container images. Run dependency scanners or package manager commands such as `npm ls hono`, `pnpm why hono`, or `yarn why hono` to identify affected versions. Add unit or integration tests that submit JWTs with malformed `exp`, `nbf`, and `iat` values and verify that they are rejected. Test examples should include strings, null values, arrays, objects, fractional numbers, extremely large values, negative values, `NaN`, and missing required time claims where the application policy requires them. Confirm that production deployments were rebuilt after dependency updates rather than only updating source manifests.

Typical attack path

1. Identify an application that uses Hono's JWT verification utility from a version prior to 4.12.18.
2. Determine whether the application accepts or generates JWTs containing malformed `exp`, `nbf`, or `iat` values.
3. Obtain the ability to influence token contents, such as through a token issuance flaw, misconfigured authentication flow, or control of the JWT signing key.
4. Create or obtain a signed JWT containing non-spec-compliant NumericDate claim values.
5. Submit the malformed token to an endpoint that calls Hono `verify()`.
6. Rely on the vulnerable validation behavior to bypass expected time-based token rejection.
7. Use the accepted token to access protected application functionality within the permissions encoded in the token.

How to detect it

There are no public, reliable, vulnerability-specific indicators of compromise for this issue. To assess whether it was already exploited, review authentication and authorization telemetry for accepted JWTs with malformed or unusual `exp`, `nbf`, or `iat` claim values. Useful sources include application authentication logs, API gateway logs, edge runtime logs, identity service logs, WAF logs, and any structured audit events that record JWT validation outcomes or decoded claims. Look for successful requests where token time claims are strings instead of numbers, arrays, objects, null values, fractional values, negative values, extremely large values, or otherwise inconsistent with normal token issuance patterns. Investigate tokens that remain accepted beyond expected expiration windows or tokens accepted before their intended validity start time. If logs do not capture decoded JWT claims, review application code and telemetry around token issuance paths to determine whether malformed claims could have been generated. Also inspect for signs of JWT signing key compromise, such as unexpected token issuers, unusual key identifiers, unexplained authentication success from new sources, or tokens not attributable to normal issuance systems.

What your security team should do

• Inventory applications and services that use Hono, especially those importing or wrapping `hono/utils/jwt`.
• Upgrade Hono to 4.12.18 or later and redeploy affected services.
• Prioritize externally exposed applications and applications where JWTs authorize access to sensitive data or privileged functions.
• Review token issuance code to ensure `exp`, `nbf`, and `iat` are emitted as valid NumericDate integer values in seconds.
• Add negative test cases for malformed JWT time claims to authentication and authorization test suites.
• Search authentication logs for unusual successful requests using tokens with abnormal or non-standard time claim values, if token claim logging is available.
• Rotate JWT signing secrets or keys if there is any evidence of signing key exposure, unauthorized token generation, or suspicious accepted tokens.
• Because there is no known exploitation, no KEV listing, no ransomware association, and a low EPSS score, handle as a scheduled but timely dependency remediation unless local exposure or key compromise increases risk.