# HSEC-2023-0015: cabal-install uses expired key policies > An attacker with a revoked key and MITM position can deliver malicious packages via cabal-install due to expired key policy handling. - **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:** 14 Nov 2025 ## What is HSEC-2023-0015? HSEC-2023-0015 is a vulnerability in cabal-install, published on 14 Nov 2025. An attacker can exploit it over the internet without logging in, with no action from the victim. ### Official description # cabal-install uses expired key policies A problem was recently discovered in `cabal-install`'s implementation of the Hackage Security protocol that would allow an attacker who was in possession of a revoked private key and who could perform a man-in-the-middle attack against Hackage to use the revoked key to deliver malicious packages. At this time, this is only a theoretical attack - no keys have been revoked. Release 3.10.2.0 of `cabal-install` contains a fix for this bug, and we have contacted distributors of older versions (such as Linux distributions) with a patch that they can apply. ## Background Hackage Security is an implementation of [The Update Framework][], which is a design for a package repository that allows untrusted mirrors without undermining software supply-chain security. In particular, Hackage Security cryptographically guarantees the following properties: * Mirrors of Hackage cannot change the contents of packages. This prevents the insertion of malicious code. * Mirrors cannot omit newer packages for more than a few days without clients noticing. This ensures both that mirrors cannot maliciously deny security updates, and that mistakes in their configuration will be noticed. Hackage has a [key policy file][] that delegates authority to a number of private keys for various purposes. Most of the keys are kept securely offline by trusted community members who annually re-sign the various files to indicate that they still have confidence in Hackage's policies. However, to prevent clients from being denied updates, Hackage has an automated process that periodically re-signs a timestamp file. This signature has a short expiry. Additionally, a snapshot file contains signed hashes of the Hackage index that is updated on each package upload. The timestamp and snapshot private keys are held in memory on the Hackage server. These are called the operational keys. If an operational key is ever compromised, then it will be revoked by having the Hackage root keyholders sign a new key policy file. To prevent replay attacks, clients that connect to Hackage after this update will reject older policy files, based on a monotonically increasing file version number. If a client has not yet received the updated policy file (for example, because they have a fresh install of `cabal-install` or because they have not run `cabal update` in some time), the built-in expiration date in the file limits the window of exposure in which the revoked operational keys would be expected. As long as the root keys have not been compromised, the compromised operational keys can only be used until the policy file expires. In addition to compromising a Hackage operational key, an attacker would additionally need to either compromise a Hackage mirror or perform a man-in-the-middle attack against the target in order to serve a malicious or obsolete package index. [key policy file]: https://hackage.haskell.org/root.json [The Update Framework]: https://theupdateframework.io/ ## The Issue A bug in `cabal-install` caused it to skip the verification of the key policy file's expiration timestamp. This means that users of older, unpatched versions of `cabal-install` could be vulnerable to a malicious mirror or man-in-the-middle attack against Hackage if they have not connected to Hackage in a long time, even after the policy file has expired. We do not believe that it has been possible to exploit this vulnerability, because no operational keys have been revoked. However, in case key revocation occurs, we strongly advise all users of `cabal-install` to ensure that they have version 3.10.2.0 or newer, which contain the fix. ## Which versions are affected by HSEC-2023-0015? 1 open source package ship an affected version, including cabal-install. | Package | Ecosystem | Affected | Fixed in | | --- | --- | --- | --- | | `cabal-install` | Hackage | From 1.24.0.0 | 3.10.2.0 | ## How do I fix HSEC-2023-0015? Upgrade cabal-install to 3.10.2.0 or later. ## Is HSEC-2023-0015 being exploited? There is no known exploitation of HSEC-2023-0015 in the wild and no public exploit code. ## Fix prompt for AI coding agents ```text Check this codebase for HSEC-2023-0015 and fix it if it is affected. What it is: HSEC-2023-0015 is a vulnerability in cabal-install, published on 14 Nov 2025. 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-2023-0015 in the wild and no public exploit code. Affected packages and fixed versions: - cabal-install (Hackage): affected from 1.24.0.0; fixed in 3.10.2.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-2023-0015/ (Markdown: https://insights.sbomify.com/HSEC-2023-0015/index.md) ``` ## Sources - OSV: https://osv.dev/vulnerability/HSEC-2023-0015 --- From sbomify Insights: https://insights.sbomify.com/HSEC-2023-0015/ Summaries are generated and may contain mistakes; the official description above is the record.