Hono: Improper validation of NumericDate claims (exp, nbf, iat) in JWT verify()

CISA KEV is observed exploitation evidence. FIRST EPSS is a dated prediction of exploitation in the next 30 days. Missing scores are unknown. This collector requests predictions only for explicit CVE aliases in the public NuGet archive; Microsoft release views retain their existing prediction scope.

No collected risk observation for these identifiers. This does not establish absence of exploitation or a zero probability.

Hono is a Web application framework that provides support for any JavaScript runtime. Prior to 4.12.18, improper validation of the JWT NumericDate claims exp, nbf, and iat in hono/utils/jwt allows tokens with non-spec-compliant claim values to silently bypass time-based checks. This issue is not exploitable by an anonymous attacker; it only manifests when a malformed claim value reaches verify() — typically when the application itself issues such tokens, or when the signing key is otherwise under attacker control. This vulnerability is fixed in 4.12.18.

Source published

13 May 2026 15:02:23 UTC

Source modified

23 Jun 2026 15:52:56 UTC

Observed here

23 Oct 2026 15:48:27 UTC

Source terms

CVE Program Terms of Use

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: cve-program · CVE Program Terms of Use. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 3.1 · 3.8 CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:L/A:N

Hono is a Web application framework that provides support for any JavaScript runtime. Prior to 4.12.18, improper validation of the JWT NumericDate claims exp, nbf, and iat in hono/utils/jwt allows tokens with non-spec-compliant claim values to silently bypass time-based checks. This issue is not exploitable by an anonymous attacker; it only manifests when a malformed claim value reaches verify() — typically when the application itself issues such tokens, or when the signing key is otherwise under attacker control. This vulnerability is fixed in 4.12.18.

Source published

May 13, 2026, 3:02:23 PM (timezone not stated)

Source modified

Jun 23, 2026, 3:52:56 PM (timezone not stated)

Observed here

28 Oct 2026 06:07:44 UTC

Source terms

ENISA EUVD · source terms and attribution apply

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: euvd · ENISA EUVD · source terms and attribution apply. Source text is retained; field grouping and change labels are provided by ChangeIntel.

EUVD CVSS 3.1 · 3.8 CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:L/A:N

Hono is a Web application framework that provides support for any JavaScript runtime. Prior to 4.12.18, improper validation of the JWT NumericDate claims exp, nbf, and iat in hono/utils/jwt allows tokens with non-spec-compliant claim values to silently bypass time-based checks. This issue is not exploitable by an anonymous attacker; it only manifests when a malformed claim value reaches verify() — typically when the application itself issues such tokens, or when the signing key is otherwise under attacker control. This vulnerability is fixed in 4.12.18.

Source published

13 May 2026 16:16:57 UTC

Source modified

26 Oct 2026 14:10:00 UTC

Observed here

27 Oct 2026 11:12:17 UTC

Source terms

NIST NVD usage terms; underlying source attribution retained

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: nvd · NIST NVD usage terms; underlying source attribution retained. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 3.1 · [email protected] · Secondary · 3.8 CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:L/A:N

### Summary Improper validation of the JWT NumericDate claims `exp`, `nbf`, and `iat` in `hono/utils/jwt` allows tokens with non-spec-compliant claim values to silently bypass time-based checks. This issue is not exploitable by an anonymous attacker; it only manifests when a malformed claim value reaches `verify()` — typically when the application itself issues such tokens, or when the signing key is otherwise under attacker control. ### Details The validation routine combined option, presence, and threshold checks in a single short-circuiting expression, so several classes of malformed values were silently skipped instead of rejected: - A falsy numeric value short-circuited the presence check. - A non-finite numeric value compared as never-after-now and never-expired. - A non-numeric type produced NaN comparisons that evaluated false. This deviates from RFC 7519 §4.1.4, which defines NumericDate as a finite JSON numeric value. ### Impact An actor able to issue tokens accepted by the application may craft tokens whose `exp`, `nbf`, or `iat` claims silently bypass time-based enforcement. This may lead to: - Tokens treated as never expiring even with `exp` configured on the verifier. - Tokens with a future `nbf` accepted as currently valid. - Tokens with a future `iat` accepted as legitimately issued. Deployments using a well-formed token issuer and protecting the signing key are not affected.

Source published

9 May 2026 00:45:19 UTC

Source modified

10 Sep 2026 03:51:05 UTC

Observed here

24 Oct 2026 13:17:17 UTC

Source terms

GitHub Advisory Database · CC-BY-4.0

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · GitHub Advisory Database · CC-BY-4.0. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS_V3 · CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:L/A:N

Publisher rating · LOW