Description
# `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 a private instance
of *hackage-server* and carefully curate and review its contents.
Using that instance exclusively defeats supply chain attacks
including *dependency confusion*. For *cabal-install < 3.4* and
where using multiple repositories, this is the only effective
mitigation against dependency confusion attacks.
Affected packages
| Ecosystem | Package | Affected | Fixed | Record |
|---|---|---|---|---|
| Hackage | cabal-install | >= 1.0.0.0, < 3.4.0.0 | 3.4.0.0 | HSEC-2025-0005 |