[Security Advisory] HSEC-2024-0004: Hackage package and doc upload stored XSS vulnerability

Announcements
1

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

48 Likes
2

Heartfelt thank you to the SRT and Hackage team for taking this on.

Like many aspects of the Haskell ecosystem, volunteers are doing essential work that benefits the entire community.

I agree that funding to the SRT and infrastructure teams is an important goal and look forward to discussing the prospectus when it is ready.

Thanks for all your work!

18 Likes
3

Hi,
It appears in your HSEC-2024-0004 that all versions of hackage-server are affected until version 0.6 where the fix occurred. When will that fix be uploaded to Hackage? Also, how will you blacklist the vulnerable versions so no one will download the bad versions?

2 Likes
4

hackage-server releases have not been updated on hackage.haskell.org for a long time, with the official deploy of hackage.haskell.org happening from Git. We did bump the version in the Git repo, and the advisory makes it clear what versions are affected (though, I will update the text to specifically mention v0.6 now that that was changed upstream). It’s a matter for the hackage-server maintainers whether to upload a new release to Hackage.

Users of Haskell should take advantage of tools that use the data from the advisory DB, such as cabal-audit, to scan their projects for known vulnerabilities. Integration with other scanning tools, such as OSV-Scanner, is a “low hanging fruit” opportunity area to improve detection capabilities.

We are also planning to file a CVE next week to increase awareness of this vulnerability, for organisations who are using hackage-server but might have missed this announcement. The SRT does not usually request CVE assignments for Haskell security issues but this is an exceptional case.

Thanks,
Fraser

7 Likes
5

Why was just a different subdomain of haskell.org used, rather than a totally different domain like googleusercontent.com and githubusercontent.com?

6

What would be the advantage of separate second-level domains? I think the current mechanism already works as intended regarding the same-origin policy?

1 Like
7

Thank you for the updates and for fixing this problem.

As this vulnerability is 9.9 (Critical) on a scale of 10 and hackage has been vulnerable for >= 18 months, how do we know whether:

  • Hackage servers have been attacked?
  • Haskell packages served by hackage are compromised?
8

Doesn’t JavaScript running on hackage-content.haskell.org have the ability to read and set cookies for the haskell.org second-level domain?

9

This is one of any number of ways by which an individual’s hackage account could be compromised. (note that there is no compromise of the hackage server itself here, just individual accounts). Other ways would include breach of a password store, social engineering, breach of any uploader’s computer, borrowing or theft of any uploader’s computer, etc etc. And then of course an individual uploader could simply choose one day to become evil and upload a compromised package. Or they could upload a broken one through error!

There never has been a way to truly know that any individual package uploaded to hackage is secure, and the most that one could hope is that it comes from the individual it claims to – and even that, even with sophisticated signing schemes, has significant vectors that could prevent it. So the answer is “the situation is the same with or without this having been a vector: you have to review the code of the packages you use, or trust others to do so”. Mitigating this has merely prevented one of many ways in which that code could be untrustworthy.

I will say that exploiting this would necessarily require upload of a malicious package with malicious documentation to hackage, and there have been no reports of such uploads, or for that matter of any other breaches of hackage accounts or malicious uploads.

1 Like
10

Yes. However the haskell.org domain does not serve a webpage, merely a redirect to www.haskell.org, which in turn is merely a static website where cookies do not matter anyway.

1 Like
11

What exactly were the blockers? I felt you were a bit vague and I think we need more clarity on this and whether it’s a structural issue.

E.g., was it access to the machines, lack of proper update procedure or simply getting a patch reviewed, tested etc.

12

I don’t believe there were blockers. Rather, as the post says “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)).”

In terms of timetable I guess I’ll add that an initial mitigation was put in place last April, which was a ten-month or so turnaround – largely consumed not by implementation blocking but a slow discussion on the proper mitigation architecture (an initial plan was much more complicated and invasive). Then there was some time in which a more thorough review was done, additional mitigations needed to be added, and at that point the advisory was made public.

2 Likes
13

Are we talking about this commit that is the fix?

If I understand it correctly, it is the quick jump functionality?

Out of curiosity: Was deactivating the feature until the fix arrived being discussed (assuming deactivating was trivial; if deactivating the feature was the mitigation after 10 months, then it appears to be a structural issue, how would throwing money on that improve the outcome in the future?)?

Anyway, I wish that this serves as a blueprint for a better next time :).

14

I still find this too vague.

It sounds to me that there were simply not enough people involved who maintain and admin the hackage-server.

So there’s a dangerous bus factor?

Mind you, such bus factor is one of the reasons the CLC exists and mitigates that for core-libraries.

Maybe we need the same for critical infrastructure.

“We’re all volunteers” isn’t really enough of an explanation to me. We can find more volunteers or start paying people if it’s that critical.

I’m not pointing fingers, but the situation has not been explained clearly enough, imo.

1 Like
15

The bus factor for infrastructure is indeed too low. This is something the infrastructure team, with some help from the HF, is trying to amend.

The problem is made worse by the fact that many of the people with the knowledge/know-how are short on time that can be used to onboard new members, their time goes to doing infrastructure things. This is one of the reasons that small bus factors are so dangerous, of course. It can take a while to get beyond “all cycles are used for putting out fires”.

That said, the infrastructure team has grown in the past several months, and we are going to continue putting effort into growing that team responsibly.

In short: Is the bus factor is too small? Yes. This isn’t the only symptom of this fact. Are we taking this very seriously? Also yes.

6 Likes
16

While it wasn’t the particular blocker here, we also have an even lower amount of people who contribute to/know the hackage codebase than are part of our general infra team. It is relatively stable (which I think is good), though could use some important refactors to its storage mechanism (which is nontrivial and requires somebody responsible and experienced, not someone itching for a fun full rewrite with the latest toys). As such, it gets relatively few contributions, and by that token there are also a limited amount of people that know the codebase well (though while large and with a few rough edges it is not particularly confusing).

Also, while the HF is working to improve things – volunteers are also always welcome, provided they can commit to ongoing, careful, and nonglamorous work.

3 Likes
17

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.

Funding and commitment are essential. When Hackage-served malware gets inside the firewall and dumps the enterprise DB to back a malicious server, nobody will really care about Haskell’s type system and its ability to prevent unrepresentable app states.

This is a watershed moment for practical Haskell. Medtechs and fintechs, as well as government agencies and contractors certainly can’t use an unpatched platform left in an open, public, critically insecure state.

Going forward, the platform will either become secure and trusted, or it won’t, and real-world users will go elsewhere. In that scenario, the Haskell job pool shrinks, and many of us in this forum will be directly impacted. On the other hand, the positive scenario is great: Commercial firms fund Haskell security, acting in their own interest while improving Haskell’s strengths as a secure, trusted platform. Going a little further, it’s easy to envision Haskell becoming the benchmark standard for highly secure system development.

Leading organizations through a watershed moment is always the hard part: Building momentum very quickly is essential so that others jump in. It’s necessary to get a string of quick wins here, asap.

(edited, minor grammar change)

2 Likes
18

But wouldn’t Session fixation § Attacks using cross-subdomain cookie be possible anyway?

1 Like
19

Fair point. Note that hackage does not use cookies for authentication, and also the possibility of such attacks requires an auth method that uses cookies and also is vulnerable to session-setting attacks. The one service that might be make use of cookies is gitlab, although I think its authentication method doesn’t allow this form of attack. Its probably better long run however to move to a new domain as you suggest.

2 Likes
20

I agree.

This is also one of the reasons that GHCup has asked the SRT for a review: Audit GHCup download practices, e.g. through the Haskell Security Response team · Issue #858 · haskell/ghcup-hs · GitHub

If we serve one malicious GHC bindist, it’s over. It’s hard to regain trust.

And this also means to me that the SRT should wield some form of authority when it comes to these matters (even if it’s merely social authority).

4 Likes