CVE-2026-40471: Hackage Server CSRF Vulnerability

CVE-2026-40471 Overview

CVE-2026-40471 is a Cross-Site Request Forgery (CSRF) vulnerability affecting hackage-server, the server software that powers the Haskell package repository. The vulnerability stems from a complete lack of CSRF protection across the server's endpoints, allowing malicious scripts on foreign websites to trigger authenticated requests to hackage-server on behalf of unsuspecting users.

This flaw enables attackers to abuse latent credentials to perform privileged actions such as uploading packages or executing administrative functions. Even unauthenticated actions are vulnerable to abuse, including the creation of new user accounts without user consent.

Critical Impact

Attackers can leverage this vulnerability to upload malicious packages to the Haskell package repository, perform administrative actions on behalf of authenticated users, or create rogue user accounts, potentially leading to supply chain attacks affecting the entire Haskell ecosystem.

Affected Products

• hackage-server (all versions prior to patch)

Discovery Timeline

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

Technical Details for CVE-2026-40471

Vulnerability Analysis

This vulnerability is classified under CWE-352 (Cross-Site Request Forgery). The fundamental issue lies in hackage-server's failure to implement CSRF tokens or other anti-forgery mechanisms across its web endpoints. When authenticated users visit a malicious website while having an active session with hackage-server, the attacker's site can craft and submit requests that the server processes as legitimate user actions.

The network-based attack vector requires minimal complexity—the attacker simply needs to lure a victim to a page containing the malicious script. The scope is changed, meaning the vulnerability can impact resources beyond the vulnerable component itself, potentially affecting the broader Haskell package ecosystem through unauthorized package uploads.

Root Cause

The root cause is the absence of CSRF protection mechanisms throughout hackage-server's implementation. Modern web applications typically employ anti-CSRF tokens that are validated on state-changing requests to ensure the request originated from the application itself. Hackage-server's endpoints lacked these protections entirely, trusting any request that contained valid session cookies regardless of origin.

Attack Vector

The attack leverages standard CSRF techniques where an attacker hosts a malicious webpage containing hidden forms or JavaScript that automatically submits requests to hackage-server endpoints. When an authenticated user visits this malicious page, their browser automatically includes session cookies with the forged request, making it appear legitimate to the server.

Attack scenarios include:

• Package Upload Abuse: An attacker could craft a form that uploads a malicious package to hackage, potentially poisoning the supply chain for Haskell developers
• Administrative Action Hijacking: Authenticated administrators could unknowingly execute privileged operations
• User Account Creation: Attackers could create numerous fake accounts for spam or reputation manipulation purposes

Since no code examples are available from verified sources, refer to the OSV Vulnerability Report HSEC-2026-0002 for additional technical details on the vulnerability mechanism and exploitation scenarios.

Detection Methods for CVE-2026-40471

Indicators of Compromise

• Unexpected package uploads or modifications in hackage-server logs not initiated by legitimate users
• Unusual administrative actions occurring without corresponding user activity
• Bulk creation of user accounts from suspicious or unexpected referrer sources
• Cross-origin requests to state-changing endpoints visible in server access logs

Detection Strategies

• Review web server access logs for requests to state-changing endpoints with suspicious Referer headers pointing to external domains
• Monitor for anomalous package upload patterns or administrative actions that don't correlate with expected user behavior
• Implement alerting on sudden spikes in new user account registrations
• Audit authentication logs for session activity that coincides with requests from unexpected sources

Monitoring Recommendations

• Enable detailed logging of all state-changing requests including Origin and Referer headers
• Implement web application firewall (WAF) rules to detect and block requests with mismatched origin headers
• Set up alerts for package uploads or modifications from users who haven't recently logged in through the standard interface
• Regularly review access patterns for administrative endpoints

How to Mitigate CVE-2026-40471

Immediate Actions Required

• Update hackage-server to the latest patched version that includes CSRF protection
• Review recent package uploads and administrative actions for signs of unauthorized activity
• Audit newly created user accounts for suspicious patterns
• Consider temporarily restricting access to critical endpoints while patching is completed

Patch Information

Refer to the OSV Vulnerability Report HSEC-2026-0002 for specific patch information and updated versions. Administrators should update to the latest version of hackage-server that includes CSRF token validation on all state-changing endpoints.

Workarounds

• Implement a reverse proxy or WAF rule that validates Origin and Referer headers match expected values before forwarding requests
• Restrict access to administrative endpoints to specific IP addresses or VPN connections
• Require re-authentication for sensitive operations like package uploads
• Educate users about the risks of maintaining active sessions while browsing untrusted websites

# Example nginx configuration to restrict based on origin
# Add to server block protecting hackage-server
location /upload {
    if ($http_origin !~* "^https://hackage\.example\.com$") {
        return 403;
    }
    proxy_pass http://hackage-backend;
}

location /admin {
    # Restrict admin endpoints to internal network
    allow 10.0.0.0/8;
    deny all;
    proxy_pass http://hackage-backend;
}