Today the Haskell Security Response Team (SRT) published an advisory concerning a critical security flaw in hackage-server, which is the software that powers hackage.haskell.org, the primary package index for the Haskell ecosystem.
You can view a rendered version of the full advisory at: https://osv.dev/vulnerability/HSEC-2024-0004. I reproduce the executive summary below, followed by some personal comments.
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 ( GitHub - haskell/hackage-server: Hackage-Server: A Haskell Package Repository ; commit 9a1887607d9b8d1a3b8b02c990ee144c0d402b79 or later), and configure the user content domain (new flag --user-content-uri).
Commentary - why did this take so long?
It was over 18 months between the SRT and other stakeholders becoming aware of this this issue, and the final mitigations being put in place. Yet it is not an exaggeration to say that this was an ecosystem-threatening vulnerability. So, why did this take so long?
Whilst the problems and fixes were certainly not trivial, they were not exceptionally complex either. The fact of the matter is this: although we (the Haskell community / ecosystem) have a security team and an infrastructure team in place, everyone is a volunteer and progress - even on such important issues as this - can be sporadic. It is fair and just that volunteer efforts are subordinate to the things that (a) uphold individual health and well-being, and (b) put food on the table and a roof over our heads (which is really a case of (a)).
If the Haskell community - including commercial users - collectively agree that this is not a satisfactory state of affairs, the way forward is to find ways to fund Haskell security work. Sustainably. There are many possible forms this could take. SRT member Montez Fitzpatrick is working on a “prospectus” to put before the Haskell Foundation and the Haskell community. It will propose a variety of funding models and hopefully push this discussion forward unto real changes that ensure the Haskell ecosystem has a sustainable and reliable security apparatus.
Another lesson learned is that having someone who is on both the Haskell SRT and the Haskell Infrastructure Admins team could be a useful policy objective. It could enable faster incident response in cases where Haskell ecosystem infrastructure is affected by security issues. We will advance this discussion during this quarter.
If you have any questions or concerns, you can reply here or reach out to the SRT at security-advisories@haskell.org.
Fraser Tweedale
on behalf of the Haskell Security Response Team