CVE-2026-40470: Hackage Server XSS Vulnerability

CVE-2026-40470 Overview

A critical Cross-Site Scripting (XSS) vulnerability has been identified in hackage-server and hackage.haskell.org, the central package repository for Haskell libraries and programs. This vulnerability stems from improper handling of HTML and JavaScript files included in source packages or uploaded via the documentation facility. These files were served without sanitization on the main hackage.haskell.org domain, creating a significant attack surface.

When users with active HTTP credentials browse package pages or documentation uploaded by a malicious package maintainer, their sessions can be hijacked. This allows attackers to upload packages or documentation, modify maintainers, alter package metadata, or perform any other action the compromised user is authorized to execute.

Critical Impact

Session hijacking through stored XSS can lead to complete account compromise, allowing attackers to manipulate packages and metadata on the Haskell package repository.

Affected Products

• hackage-server (all versions prior to patch)
• hackage.haskell.org (production instance)
• Any self-hosted hackage-server deployments serving untrusted content

Discovery Timeline

• 2026-04-23 - CVE CVE-2026-40470 published to NVD
• 2026-04-23 - Last updated in NVD database

Technical Details for CVE-2026-40470

Vulnerability Analysis

This vulnerability is classified as CWE-79 (Improper Neutralization of Input During Web Page Generation), commonly known as Cross-Site Scripting (XSS). The root issue lies in the hackage-server's content serving mechanism, which fails to properly sanitize or isolate user-uploaded content.

The vulnerability represents a stored XSS attack vector, where malicious JavaScript or HTML content persists on the server within package documentation or source files. When other users access these resources, the malicious code executes within the context of the main hackage.haskell.org domain, inheriting the victim's session and authentication state.

The network-based attack vector with low attack complexity makes this particularly dangerous. An authenticated package maintainer with even minimal privileges can inject malicious content that affects any user who views their package pages or documentation, potentially including repository administrators and other high-privilege accounts.

Root Cause

The root cause is the lack of content isolation and sanitization for user-uploaded files. HTML and JavaScript files included in package source distributions or uploaded through the documentation facility were served directly from the main domain without:

1. Content-Type validation or enforcement
2. Sandboxing via separate domains or Content Security Policy headers
3. Input sanitization to strip or escape potentially malicious content
4. Isolation of user-generated content from authenticated sessions

Attack Vector

The attack exploits the trust relationship between the hackage.haskell.org domain and authenticated users. A malicious package maintainer uploads crafted HTML or JavaScript files either as part of their package source or through the documentation upload feature. When a victim with an active session browses to the compromised content, the malicious scripts execute with full access to the victim's cookies and session tokens.

The attacker can then leverage this access to perform actions on behalf of the victim, including uploading new packages, modifying existing package metadata, changing maintainer lists, or even compromising other packages the victim maintains. This creates a potential supply chain attack vector affecting the entire Haskell ecosystem.

Detection Methods for CVE-2026-40470

Indicators of Compromise

• Unusual documentation or source file uploads containing embedded JavaScript or suspicious HTML tags
• Unexpected changes to package maintainer lists or metadata without legitimate justification
• Session cookies being accessed from unusual IP addresses or user agents following visits to specific package pages
• Package uploads or modifications occurring shortly after users browse untrusted package documentation

Detection Strategies

• Monitor web server logs for requests to documentation files containing suspicious query parameters or fragment identifiers
• Implement Content Security Policy (CSP) reporting to identify script execution from unexpected sources
• Review recent package uploads and documentation changes for HTML files containing <script> tags or inline event handlers
• Deploy client-side XSS detection mechanisms that alert on suspicious DOM modifications

Monitoring Recommendations

• Enable detailed logging for all authenticated actions on the hackage-server instance
• Set up alerts for bulk or automated changes to package metadata or maintainer lists
• Monitor for unusual patterns in documentation upload frequency or content size anomalies
• Implement session monitoring to detect concurrent sessions from geographically disparate locations

How to Mitigate CVE-2026-40470

Immediate Actions Required

• Apply the latest security patches to hackage-server deployments immediately
• Audit recent package uploads and documentation changes for suspicious HTML or JavaScript content
• Consider temporarily restricting documentation upload capabilities until patches are applied
• Review and potentially invalidate active user sessions if compromise is suspected
• Notify users who may have accessed suspicious package documentation to rotate their credentials

Patch Information

Organizations running hackage-server should consult the official security advisory for patch details. For additional technical information about this vulnerability, refer to the OSV Vulnerability HSEC-2024-0004 advisory.

Users of the public hackage.haskell.org service should ensure they are not accessing cached versions of documentation and should clear browser data after the fix is deployed.

Workarounds

• Serve user-uploaded content from a separate domain that does not share cookies with the main hackage domain
• Implement strict Content Security Policy headers that prevent inline script execution
• Use the sandbox attribute on iframes when displaying user-uploaded documentation
• Configure the server to serve user-uploaded HTML with Content-Type: text/plain to prevent browser rendering
• Disable JavaScript execution in documentation by stripping script tags during the upload process

# Example CSP header configuration for nginx
# Add to server block to mitigate XSS until patched

add_header Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; frame-ancestors 'none';" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "DENY" always;