CVE-2024-47174: Nix Package Manager TLS Verification Flaw

CVE-2024-47174 Overview

CVE-2024-47174 affects the Nix package manager on Linux and Unix systems. The builtin derivation builder builtin:fetchurl, exposed as <nix/fetchurl.nix>, did not verify TLS certificates on HTTPS connections. An attacker positioned between the Nix client and a remote store can intercept traffic, harvest credentials from netrc files or impureEnvVars, and inject arbitrary store objects through the trust-on-first-use (TOFU) workflow. The flaw was introduced in Nix 1.11 and remained present until versions 2.18.8 and 2.24.8. The weakness is categorized as [CWE-287] Improper Authentication.

Critical Impact
A man-in-the-middle attacker can steal fetch credentials and inject malicious store artifacts into Nix builds that use the builtin fetchurl derivation.

Affected Products

Nix versions 1.11 through 2.18.7
Nix versions 2.19.0 through 2.24.7
Any derivation using <nix/fetchurl.nix> or builtin:fetchurl on affected Nix releases

Discovery Timeline

2024-09-26 - CVE-2024-47174 published to NVD with GitHub Security Advisory GHSA-6fjr-mq49-mm2c
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2024-47174

Vulnerability Analysis

The vulnerability is a missing TLS certificate validation flaw in the builtin fetcher used by Nix derivations. builtin:fetchurl is distinct from the evaluation-time function builtins.fetchurl, which is not affected. When a derivation calls the builtin fetcher, the download routine in src/libstore/builtins/fetchurl.cc sets request.verifyTLS = false, instructing libcurl to skip certificate chain and hostname validation.

Two exploitation paths follow. First, Nix forwards authentication material—netrc entries and environment variables listed under impureEnvVars—to the fetcher over the attacker-controlled TLS session, leaking those credentials. Second, when a user updates a dependency with an invalid hash to let the store report the real hash (the common TOFU workflow), a MITM can serve arbitrary content and have its hash pinned into the project.

Root Cause

TLS verification was disabled intentionally because the fetcher validates the output hash afterwards and because early sandbox builds lacked access to the CA bundle. CA bundles are now bind-mounted into the Linux build sandbox, so the exception is no longer needed. The hash check also fails to protect flows where the hash is not yet known, such as TOFU updates and impure derivations.

Attack Vector

Exploitation requires network-adjacent interception of HTTPS traffic between the Nix client and the configured remote source. Once positioned, the attacker presents any TLS certificate, serves tampered payloads, and captures Authorization headers or credentials supplied through netrc and impureEnvVars.

text

// Vulnerable code path in src/libstore/builtins/fetchurl.cc (removed by patch)
auto source = sinkToSource([&](Sink & sink) {

    /* No need to do TLS verification, because we check the hash of
       the result anyway. */
    FileTransferRequest request(url);
    request.verifyTLS = false;
    request.decompress = false;

    auto decompressor = makeDecompressionSink(

Source: GitHub commit 062b4a4

Detection Methods for CVE-2024-47174

Indicators of Compromise

Unexpected changes to pinned hashes in flake.lock, default.nix, or vendored fetcher expressions following a dependency update
Store paths produced by builtin:fetchurl whose contents do not match the upstream artifact published by the vendor
Outbound HTTPS connections from Nix builders to IP addresses that do not resolve to the expected upstream host

Detection Strategies

Inventory Nix installations and flag any version below 2.18.8 on the 2.18 branch or below 2.24.8 on the 2.24 branch
Grep build expressions for import <nix/fetchurl.nix> and builtin:fetchurl usage to identify derivations that relied on the vulnerable path
Compare the hashes of recently fetched store objects against upstream-published checksums to find TOFU-era substitutions

Monitoring Recommendations

Capture TLS metadata from build hosts and alert on certificates that fail validation when replayed through a verifying client
Forward Nix daemon logs into a centralized data lake and correlate downloading events with downstream hash mismatches
Monitor netrc reads and impureEnvVars propagation on CI runners that execute Nix builds

How to Mitigate CVE-2024-47174

Immediate Actions Required

Upgrade Nix to 2.18.8, 2.24.8, or later on every developer workstation, CI runner, and build server
Rotate any credentials that may have been exposed through netrc or impureEnvVars while the vulnerable fetcher was in use
Re-verify hashes for dependencies introduced via TOFU updates against upstream-published values

Patch Information

The fix removes the request.verifyTLS = false assignment in src/libstore/builtins/fetchurl.cc, restoring certificate validation for builtin:fetchurl. See GitHub Pull Request #11585, commits 062b4a4 and 5db358d, and advisory GHSA-6fjr-mq49-mm2c.

Workarounds

Replace builtin:fetchurl with pkgs.fetchurl from Nixpkgs, which performs authenticated fetching with proper TLS verification
Pass credentials through impureEnvVars combined with curlOpts on pkgs.fetchurl instead of relying on the builtin fetcher
Avoid the fake-hash TOFU workflow on unpatched systems; obtain hashes from a trusted upstream channel before adding dependencies

bash

# Replace builtin:fetchurl with pkgs.fetchurl in a derivation
{ pkgs ? import <nixpkgs> {} }:
pkgs.fetchurl {
  url = "https://example.com/artifact.tar.gz";
  sha256 = "<known-good-hash>";
  curlOpts = "--cacert /etc/ssl/certs/ca-certificates.crt";
}