https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sun, 04 Oct 2026 08:10:31 +0000 https://cve.radiocsirt.org/vuln/brew-cabal-install-hsec-2025-0005 <p><strong>Affected:</strong> Homebrew: cabal-install</p> <p># `cabal-install` dependency confusion</p> <p>For **cabal-install &lt; 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.</p> <p>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.</p> <p>[blog]: https://frasertweedale.github.io/blog-fp/posts/2021-02-12-haskell-dependency-confusion.html</p> <p>## Mitigations</p> <p>*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:</p> <p>``` -- For packages in repo.example.com, -- only versions in repo.example.com are considered active-repositories: , hackage.haskell.org , repo.example.com:override ```</p> <p>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.</p> <p>Alternatively, projects and organisations can run…</p> <p><strong>Affected:</strong> Homebrew: cabal-install</p> <p># `cabal-install` dependency confusion</p> <p>For **cabal-install &lt; 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.</p> <p>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.</p> <p>[blog]: https://frasertweedale.github.io/blog-fp/posts/2021-02-12-haskell-dependency-confusion.html</p> <p>## Mitigations</p> <p>*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:</p> <p>``` -- For packages in repo.example.com, -- only versions in repo.example.com are considered active-repositories: , hackage.haskell.org , repo.example.com:override ```</p> <p>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.</p> <p>Alternatively, projects and organisations can run…</p> https://cve.radiocsirt.org/vuln/brew-cabal-install-hsec-2025-0005