JustAppSec
Back to news

Hackage-server mitigates stored XSS enabling maintainer session hijack

2 min readPublished 23 Apr 2026Updated 23 Apr 2026Source: CVEProject (cvelistV5)

TL;DR — A Critical stored XSS in hackage-server can let a malicious package maintainer run JavaScript on hackage.haskell.org’s main origin and hijack other maintainers’ sessions to perform repository actions.

What happened

Hackage is the primary package index for the Haskell ecosystem, and hackage-server is the web application that powers Hackage instances (including package pages, source tarball browsing, and hosted documentation).

CVE-2026-40470 describes a Critical stored XSS condition where HTML and JavaScript provided in source packages or via the documentation upload facility were served as-is on the main hackage.haskell.org domain. The impact called out in the advisory is account/session abuse: when a user with “latent HTTP credentials” visits a package page or docs uploaded by a malicious maintainer, attacker-controlled script can act as that user to upload packages/docs, amend maintainers/metadata, or perform other authorized actions.

From a platform risk perspective, this is a classic “shared-origin repository UI” failure mode: once an attacker can execute script on the primary repository origin, they can often pivot into supply-chain impact (publishing or modifying artifacts) even if the initial bug is “just XSS.”

Who is impacted

  • Operators of self-hosted hackage-server instances, particularly those serving user-uploaded documentation or source browsing from the main site origin.
  • The CVE record lists hackage-server versions >= 0.1 and < 0.6 as affected.
  • Maintainers/admins whose browsers present “latent” credentials to the Hackage web origin are the highest-value targets (the issue is explicitly framed as session hijack leading to privileged repository actions).
ComponentAffected (per CVE record)
hackage-server>= 0.1, < 0.6

What to do now

  • Follow vendor remediation guidance and apply the latest patched/mitigated deployment available at the time of writing.
  • If you operate hackage-server outside the official hackage.haskell.org service, adopt the mitigation pattern described in the linked OSV advisory (HSEC-2024-0004): serve user-uploaded content from a separate “user content” domain and configure it via --user-content-uri.

    "Operators of other hackage-server instances should update to the master branch from the upstream repository" "and configure the user content domain (new flag --user-content-uri)."

  • Audit exposure:
    • Identify whether your instance serves documentation bundles or source tarball HTML from the main origin (same scheme/host as the authenticated UI).
    • Review whether any privileged users rely on “latent” browser credentials for the repository UI (and consider requiring stronger re-auth for high-impact actions like publishing).
  • If compromise is suspected, treat it as a potential repository integrity incident: review publish/metadata change history, then rotate credentials/tokens used for package publishing and administration.

Additional Information

  • The OSV advisory linked from the CVE (HSEC-2024-0004) notes that the known issues were “fully mitigated on hackage.haskell.org as of January 2026,” but self-hosted instances may still be exposed if they haven’t deployed the same mitigations.
  • The mitigation described includes moving user content to a sister domain (for hackage.haskell.org, hackage-content.haskell.org) to break the dangerous “trusted UI + untrusted content” same-origin relationship.

Content is AI-assisted and reviewed by our team, but issues may be missed and best practices evolve rapidly, send corrections to [email protected]. Always consult official documentation and validate key implementation decisions before making design or security choices.

Need help?Get in touch.