{"answers":{"affected":"1 open source package ship an affected version, including cabal-install.","exploited":"There is no known exploitation of HSEC-2023-0015 in the wild and no public exploit code.","fix":"Upgrade cabal-install to 3.10.2.0 or later.","what":"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."},"fix_prompt":"Check this codebase for HSEC-2023-0015 and fix it if it is affected.\n\nWhat 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.\nExploitation: There is no known exploitation of HSEC-2023-0015 in the wild and no public exploit code.\n\nAffected packages and fixed versions:\n- cabal-install (Hackage): affected from 1.24.0.0; fixed in 3.10.2.0\n\nTask:\n1. 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.\n2. 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.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/HSEC-2023-0015/ (Markdown: https://insights.sbomify.com/HSEC-2023-0015/index.md)","id":"HSEC-2023-0015","markdown":"https://insights.sbomify.com/HSEC-2023-0015/index.md","name":"HSEC-2023-0015","record":{"aliases":[],"analysis":{"component_type":"developer_tool","fix_type":"upgrade","impacts":["code_execution"],"network_reachable":"yes","non_default_config":false,"product_category":"Haskell package manager","requires_auth":"none","summary":"An attacker with a revoked key and MITM position can deliver malicious packages via cabal-install due to expired key policy handling.","user_interaction":"not_required","vuln_class":"supply_chain"},"analysis_generated_by":"qwen3.8-flash-next","assigner":null,"cpe":[],"cvss":{"score":null,"severity":null,"source":null,"vector":null,"version":null},"cwes":[],"description":"# cabal-install uses expired key policies\n\nA problem was recently discovered in `cabal-install`'s\nimplementation of the Hackage Security protocol that would allow an\nattacker who was in possession of a revoked private key and who\ncould perform a man-in-the-middle attack against Hackage to use the\nrevoked key to deliver malicious packages. At this time, this is\nonly a theoretical attack - no keys have been revoked. Release\n3.10.2.0 of `cabal-install` contains a fix for this bug, and we have\ncontacted distributors of older versions (such as Linux\ndistributions) with a patch that they can apply.\n\n## Background\n\nHackage Security is an implementation of [The Update Framework][],\nwhich is a design for a package repository that allows untrusted\nmirrors without undermining software supply-chain security. In\nparticular, Hackage Security cryptographically guarantees the\nfollowing properties:\n\n * Mirrors of Hackage cannot change the contents of packages. This\n   prevents the insertion of malicious code.\n\n * Mirrors cannot omit newer packages for more than a few days\n   without clients noticing. This ensures both that mirrors cannot\n   maliciously deny security updates, and that mistakes in their\n   configuration will be noticed.\n\nHackage has a [key policy file][] that delegates authority to a\nnumber of private keys for various purposes. Most of the keys are\nkept securely offline by trusted community members who annually\nre-sign the various files to indicate that they still have\nconfidence in Hackage's policies. However, to prevent clients from\nbeing denied updates, Hackage has an automated process that\nperiodically re-signs a timestamp file. This signature has a short\nexpiry. Additionally, a snapshot file contains signed hashes of the\nHackage index that is updated on each package upload. The timestamp\nand snapshot private keys are held in memory on the Hackage server.\nThese are called the operational keys. If an operational key is ever\ncompromised, then it will be revoked by having the Hackage root\nkeyholders sign a new key policy file. To prevent replay attacks,\nclients that connect to Hackage after this update will reject older\npolicy files, based on a monotonically increasing file version\nnumber.\n\nIf a client has not yet received the updated policy file (for\nexample, because they have a fresh install of `cabal-install` or\nbecause they have not run `cabal update` in some time), the built-in\nexpiration date in the file limits the window of exposure in which\nthe revoked operational keys would be expected. As long as the root\nkeys have not been compromised, the compromised operational keys can\nonly be used until the policy file expires. In addition to\ncompromising a Hackage operational key, an attacker would\nadditionally need to either compromise a Hackage mirror or perform a\nman-in-the-middle attack against the target in order to serve a\nmalicious or obsolete package index.\n\n[key policy file]: https://hackage.haskell.org/root.json\n[The Update Framework]: https://theupdateframework.io/\n\n## The Issue\n\nA bug in `cabal-install` caused it to skip the verification of the\nkey policy file's expiration timestamp. This means that users of\nolder, unpatched versions of `cabal-install` could be vulnerable to\na malicious mirror or man-in-the-middle attack against Hackage if\nthey have not connected to Hackage in a long time, even after the\npolicy file has expired.\n\nWe do not believe that it has been possible to exploit this\nvulnerability, because no operational keys have been revoked.\nHowever, in case key revocation occurs, we strongly advise all users\nof `cabal-install` to ensure that they have version 3.10.2.0 or\nnewer, which contain the fix.","ecosystems":["Hackage"],"exploits":{"exploitdb":null,"first_seen":null,"github_poc":null,"max_poc_stars":null,"metasploit":null,"nuclei":null,"refs":[],"tier":null},"has_fix":true,"headline":"cabal-install uses expired key policies","id":"HSEC-2023-0015","indexable":true,"kev":null,"kind":"advisory","links":{"ecosystem":null,"product":null,"products":[],"type":"supply_chain","year":"2025"},"n_packages":1,"n_references":null,"packages":[{"ecosystem":"Hackage","fixed":["3.10.2.0"],"introduced":["1.24.0.0"],"last_affected":[],"package":"cabal-install","purl":"pkg:hackage/cabal-install","source":"HSEC-2023-0015"}],"products":null,"published":"2025-11-14","related":[],"sources":[{"class":"open","licence":"CC0 1.0","name":"Haskell Security Response Team","prefix":"HSEC"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":null,"updated":null,"vendors":null},"summary":"An attacker with a revoked key and MITM position can deliver malicious packages via cabal-install due to expired key policy handling.","url":"https://insights.sbomify.com/HSEC-2023-0015/"}