Most recent entries from osv_haskell

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

Tue, 29 Sep 2026 14:22:37 +0000

Affected: Hackage: jwt

# 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…

HSEC-2026-0008 — crypton-x509-validation and crypton-x509 do not enforce X.509 Name Constraints

Wed, 03 Jun 2026 13:30:48 +0000

Affected: Hackage: crypton-x509-validation, Hackage: crypton-x509, Hackage: x509-validation, Hackage: x509

# crypton-x509-validation and crypton-x509 do not enforce X.509 Name Constraints

The `crypton-x509-validation` and `crypton-x509` libraries did not enforce the X.509 Name Constraints extension during certificate validation. The Name Constraints extension is a critical X.509 extension that restricts the namespace (permitted and excluded subtrees) for which a CA is authorized to issue certificates.

Without this enforcement, a TLS client would accept certificates with Subject Alternative Names (SANs) that fall outside the issuing CA's permitted subtrees. An attacker with access to a name-constrained sub-CA's private key could therefore issue certificates for domains outside the sub-CA's intended scope, enabling impersonation of arbitrary domains and man-in-the-middle attacks on TLS connections.

The older `x509` and `x509-validation` packages are also affected but are no longer maintained and have no fix available.

This issue was fixed in `crypton-x509-validation-1.9.1` and `crypton-x509-1.9.1`.

HSEC-2026-0007 — Denial of Service and Memory Exhaustion in aeson

Fri, 22 May 2026 07:02:58 +0000

Affected: Hackage: aeson, Hackage: text-iso8601

# Denial of Service and Memory Exhaustion in aeson

A Denial of Service (DoS) and memory exhaustion vulnerability was identified in the `aeson` package. The vulnerability allows an attacker to exhaust server memory and crash the host process by supplying maliciously crafted JSON payloads.

The vulnerability exists in `aeson`'s `withBoundedScientific_` function (located in `src/Data/Aeson/Types/FromJSON.hs`). The exponent bounds check only rejects large positive exponents (`exp10 > 1024`) but fails to reject arbitrarily large negative exponents.

When an attacker sends a JSON number with a massive negative exponent (e.g., `1e-999999999`), the value bypasses the check and flows into `realToFrac`, which computes `fromRational . toRational`. For such a large negative exponent, `toRational` produces a GMP Integer with approximately 1 billion decimal digits, causing immediate and severe memory exhaustion.

Affected `FromJSON` instances:

* `Fixed a` (including `Centi`, `Pico`, `Nano`, etc.) * `NominalDiffTime` * `DiffTime`

## Resolution

The issue was resolved by introducing proper bounds checks:

- `aeson` now applies an absolute bounds check to both positive and negative exponents (`abs exp10 > 1024`).

The fix first shipped in `aeson-2.3.0.0`, and have been backported to the previous release series as `aeson-2.2.5.1`.

Users are strongly advised to update to the patched versions:

* `aeson-2.2.5.1` or later

## Acknowledgements

The vulnerabilities were reported Nathan Walsh,…

HSEC-2026-0006 — Cabal deletes project source files during configure

Wed, 08 Apr 2026 14:23:27 +0000

Affected: Hackage: Cabal

# Cabal deletes project source files during configure

The `checkDuplicateHeaders` function in `Distribution.Simple.Configure` removes header files from the source directory when a header with the same name exists in both the build directory and the source directory.

This behavior was introduced in commit `3a9830b` to resolve header precedence issues, as C compilers prefer relative includes over `-I` search paths. The workaround uses `removeFile` on source directory files, which is destructive and should not happen during a build process.

While the current implementation does not follow symlinks explicitly, the deletion of source files outside of the project during a build operation is possible on Microsoft Windows.

HSEC-2026-0004 — Hackage package metadata stored XSS vulnerability

Sat, 28 Mar 2026 16:05:12 +0000

Affected: Hackage: hackage-server

# Hackage package metadata stored XSS vulnerability

User-controlled metadata from `.cabal` files are rendered into HTML `href` attributes without proper sanitization, enabling stored Cross-Site Scripting (XSS) attacks. The specific fields affected are:

- `homepage` - `bug-reports` - `source-repository.location` - `description` (Haddock hyperlinks)

The Haskell Security Response Team audited the entire corpus of **published** packages on `hackage.haskell.org`—all published package versions but *not* candidates. No exploitation attempts were detected.

To fix the issue, *hackage-server* now inspects target URIs and only produces a hyperlink when the URI has an approved scheme: `http`, `https`, and (only for some fields) `mailto`.

The fix has been [committed][commit] and deployed on `hackage.haskell.org`. Other operations of *hackage-server* instances should update as soon as possible to commit `2de3ae45082f8f3f29a41f6aff620d09d0e74058` or later.

## Acknowledgements

- **Joshua Rogers** (https://joshua.hu/) of AISLE (https://aisle.com/) reported the issue to the Haskell Security Response Team. - **Fraser Tweedale** implemented the fix. - **Gershom Bazerman** merged the fix and deployed it to `hackage.haskell.org`.

[commit]: https://github.com/haskell/hackage-server/commit/2de3ae45082f8f3f29a41f6aff620d09d0e74058

HSEC-2026-0002 — Hackage CSRF vulnerability

Sat, 28 Mar 2026 16:04:58 +0000

Affected: Hackage: hackage-server

# Hackage CSRF vulnerability

* Vulnerable File: `src/Distribution/Server/Features/Votes.hs` (example) * Impact: can forge requests through XSS

hackage-server lacked Cross-Site Request Forgery (CSRF) protection across its endpoints. Scripts on foreign sites could trigger requests to hackage server, possibly abusing latent credentials to upload packages or perform other administrative actions. Some unauthenticated actions could also be abused (e.g. creating new user accounts).

To fix the issue, a new CSRF middleware checks all requests. Requests using HTTP methods other than `GET`, `HEAD` and `OPTIONS` are subject to a check of the [`Sec-Fetch-Site` header][sec-fetch-site], which is [widely supported by modern browsers][caniuse-sec-fetch-site]. Cross-site requests are `403 Forbidden`. Certain approved and expected non-browser user agents (e.g. `cabal-install/*`) are exempted from the check, as are requests using token authentication (`Authorization: X-ApiKey ...`).

The fix has been [committed][commit] and deployed on `hackage.haskell.org`.

## Acknowledgements

- **Joshua Rogers** (https://joshua.hu/) of AISLE (https://aisle.com/) reported the issue to the Haskell Security Response Team. - **Spenser Janssen** implemented the fix, and **Fraser Tweedale** reviewed it. - **Gershom Bazerman** merged the fix and deployed it to `hackage.haskell.org`.

[sec-fetch-site]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Sec-Fetch-Site [caniuse-sec-fet…

HSEC-2024-0004 — Hackage package and doc upload stored XSS vulnerability

Fri, 16 Jan 2026 11:18:20 +0000

Affected: Hackage: hackage-server

# Hackage package and doc upload stored XSS vulnerability

*Author: Fraser Tweedale (Haskell SRT)*

## Executive summary

A **critical XSS vulnerability** affected *hackage-server* and `hackage.haskell.org`. HTML and JavaScript files provided in source packages or via the documentation upload facility were served *as-is* on the main `hackage.haskell.org` domain. As a consequence, when a user with latent HTTP credentials browses to the package pages or documentation uploaded by a malicious package maintainer, their **session can be hijacked** to upload packages or documentation, amend maintainers or other package metadata, or perform any other action the user is authorised to do.

This issue was discovered and reported to the Haskell Security Response Team (SRT) in June 2024. Remediations were progressively developed and deployed throughout 2025. **The known issues have been fully mitigated on `hackage.haskell.org` as of January 2026.**

The mitigations involve serving user content from a sister domain. In the case of `hackage.haskell.org`, this domain is `hackage-content.haskell.org`.

Operators of other *hackage-server* instances should update to the `master` branch from the upstream repository (https://github.com/haskell/hackage-server; commit `9a1887607d9b8d1a3b8b02c990ee144c0d402b79` or later), and configure the user content domain (new flag `--user-content-uri`).

## Scope of the issue

### Package documentation uploads

Any Hackage user can upload documentation bun…

HSEC-2025-0007 — cmark-gfm: resource exhaustion due to quadratic complexity in parser

Sat, 27 Dec 2025 08:58:56 +0000

Affected: Hackage: cmark-gfm

# cmark-gfm: resource exhaustion due to quadratic complexity in parser

*cmark-gfm* is GitHub's fork of *cmark*, a CommonMark parsing and rendering library and program in C. A polynomial time complexity issue in cmark-gfm may lead to unbounded resource exhaustion and subsequent denial of service, due to quadratic complexity issues when parsing text which leads with either large numbers of `>` or `-` characters.

The Haskell *cmark-gfm* package bundles the C sources and was affected by this issue. This fix was released in the upstream C package at version `0.29.0.gfm.10`. Version `0.2.6` of the Haskell package adopted the fix (moving from `0.29.0.gfm.6` to `0.29.0.gfm.13`). Packages that depend on *cmark-gfm* should update to `0.2.6` or later.

Users unable to update should avoid processing data from untrusted sources or validate the input with other tools before using *cmark-gfm* to parse it.

Pandoc `< 2.10.1` depended on *cmark-gfm* and could be affected by this issue.

HSEC-2025-0006 — Private key leak via inherited file descriptor

Mon, 17 Nov 2025 02:22:38 +0000

Affected: Hackage: x509-store, Hackage: crypton-x509-store

# Private key leak via inherited file descriptor

The X.509 key reading function `readKeyFile` opened a file descriptor to the private key without setting the *close-on-exec* flag. If a child process is `exec`ed at the same time, it would inherit that file descriptor and could read the private key material.

Impact is limited to child processes that run untrusted code, but that do not close inherited file descriptors. (For example, the `su(1)` command.)

This leak was fixed by setting the *close-on-exec* flag on unix-based systems.

HSEC-2025-0005 — cabal-install dependency confusion

Fri, 14 Nov 2025 14:45:34 +0000

Affected: Hackage: cabal-install

# `cabal-install` dependency confusion

For **cabal-install < 3.4.0.0** and where multiple repositories are configured, the resolver picks the highest available version across all repositories. Where a package is only defined in a private repository, this behaviour leads to a [*dependency confusion*][blog] supply chain vulnerability. If the private package name becomes known, a malicious actor can claim the name in the public repository and publish a malicious version at a higher version number.

Default `cabal-install` configurations that only use the `hackage.haskell.org` repository are not affected. Configurations that use curated private repositories **exclusively** are also not affected.

[blog]: https://frasertweedale.github.io/blog-fp/posts/2021-02-12-haskell-dependency-confusion.html

## Mitigations

*cabal-install* version **3.4.0.0** and higher provide an `override` option in the repository configuration. It marks the associated repository as canonical for all packages defined in that repository. No other repositories will be considered. For example:

``` -- For packages in repo.example.com, -- only versions in repo.example.com are considered active-repositories: , hackage.haskell.org , repo.example.com:override ```

Users and organisations using private repositories that contain private packages in addition to public repositories **MUST** use the `override` option to prevent dependency confusion attacks.

Alternatively, projects and organisations can run…