GNU Guix Flaws Allow Remote Privilege Escalation Through Malicious Binary Substitutes

GNU Guix developers have fixed four security vulnerabilities that could allow malicious substitute servers to write arbitrary files, expose local data, redirect package requests or overwrite files through crafted channel names.

The most serious attack could lead to remote privilege escalation when Guix downloads a specially prepared binary substitute. The impact becomes particularly severe when guix-daemon runs as root because an attacker may gain the ability to modify sensitive system files.

The project fixed the vulnerabilities through changes included in Guix pull request 9665. Users should update both Guix and guix-daemon to commit 897832f374dcdc9eeaf19d01e70b9a92fccfc68c or a later revision.

Four vulnerabilities affect Guix substitutes and channels

Three vulnerabilities affect guix substitute, the component that downloads prebuilt package results from substitute servers. The fourth affects channel handling in guix pull and guix time-machine.

Guix substitutes let users download previously built store items instead of compiling packages locally. Guix verifies substitute metadata and content to protect users from unauthorized packages, as described in the project’s substitute documentation.

The disclosed flaws weakened different parts of that security model. Attackers could target systems through a malicious substitute source, a network interception attack, an untrusted local client or a controlled channel definition.

Affected component	Vulnerability	Potential impact
guix substitute	Archive extraction before complete verification	Arbitrary file writes and possible privilege escalation
guix substitute	Substitute metadata request confusion	Installation of an unintended signed store item
guix substitute	Local file URL information disclosure	Exposure of files readable by the daemon user
guix pull and guix time-machine	Channel cache path traversal	Creation or replacement of user-writable files

Malicious substitutes could write arbitrary files

The most critical vulnerability affected the restore-file procedure used when Guix unpacked binary substitutes. Guix could begin extracting an archive while it was still downloading, before confirming the complete archive hash.

A malicious substitute server could exploit this behavior by sending a crafted archive containing dangerous paths. Those paths could cause the extraction process to write files outside the intended Guix store location.

The attacker could write any file accessible to the account running guix-daemon. On systems where the daemon runs as root, this may include highly sensitive locations and could result in full system compromise.

• A Guix client requests a binary substitute.
• The substitute server returns signed metadata that appears acceptable.
• The server begins delivering a specially crafted archive.
• Guix extracts archive content before validating the complete download.
• Malicious paths write files outside the expected destination.

The final effect depends on the daemon account’s permissions. A root daemon could potentially modify files such as /etc/passwd, startup configuration, service definitions or executable files used by privileged processes.

The attack does not require control of an official Guix server

An attacker does not need to compromise the official Guix substitute infrastructure. The vulnerable behavior can affect downloads from any substitute server that a user or administrator has authorized.

This includes manually configured substitute sources and servers found through the daemon’s discovery feature. Guix administrators should therefore review every substitute URL and public key trusted by their systems.

The GNU Guix manual explains that substitute servers provide signed metadata describing store items. The security issue arose because valid metadata did not safely constrain every part of the later download and extraction process.

Using HTTPS reduces some network risks, but it does not fully address the vulnerability. A legitimate but malicious substitute source can still serve harmful content, while weaknesses in the download binding could create opportunities for network attackers under certain conditions.

Signed metadata did not securely bind the download URL

Guix uses narinfo files to describe binary substitutes. A narinfo record includes information such as the store path, archive location, compression method, hashes and signatures.

The vulnerable implementation did not securely bind every substitute download URL to the signed metadata. This created a gap between the item authorized by a signature and the location from which Guix downloaded the archive.

A malicious source or network attacker could exploit that gap to influence the content delivered to the vulnerable extraction process. The archive could begin changing files before Guix detected that its final hash did not match.

Security control	Expected protection	Vulnerable behavior
Narinfo signature	Confirms that substitute metadata comes from an authorized source	Did not safely constrain every download location involved in the request
Archive hash	Confirms that downloaded content matches the expected store item	Verification occurred after extraction had already started
Store path validation	Keeps package data inside the expected Guix store	Crafted archive paths could write outside the intended destination

The patched implementation verifies the relevant content and strengthens URL handling before allowing substitute data to affect the filesystem.

A metadata confusion flaw could return the wrong package

A second vulnerability allowed a substitute source to return authorized metadata for one store item when the client had requested another.

The returned item could still carry a valid signature, but it would not necessarily match the package or store path the client intended to retrieve. This could make Guix accept an unintended store item.

An attacker could potentially use the weakness to force a system to retrieve an older, vulnerable or otherwise undesirable software build, provided an appropriately signed store item already existed.

• The client requests metadata for a specific store item.
• A malicious server returns valid metadata for a different item.
• The returned metadata carries an authorized signature.
• Vulnerable Guix code fails to enforce the original request correctly.
• The client may download or use an unintended substitute.

This issue does not let an attacker create an arbitrary valid Guix package signature. Instead, it allows the attacker to misuse already authorized metadata by returning it in response to the wrong request.

Local clients could expose files through file URLs

The third guix substitute vulnerability involved file:// URLs. A local client with access to the guix-daemon socket could direct the daemon toward a file on the local system.

If Guix attempted to parse that file as substitute metadata and encountered an error, parts of the file could appear in an error backtrace returned to the requesting client.

This could expose data from files that the client could not read directly but that remained accessible to the guix-daemon account.

Condition	Required access	Possible result
Attacker reaches the default daemon socket	Local access as an untrusted Guix client	Can submit requests to guix-daemon
Daemon accepts a file URL	Target file must be readable by the daemon	Guix attempts to parse local content as narinfo metadata
Parsing produces a backtrace	Malformed or unexpected local file content	Parts of the file may return to the client

The amount and type of leaked information depend on the target file and the generated parsing error. On a root-operated daemon, the readable file set may include sensitive system configuration and secrets unavailable to ordinary users.

Channel names enabled a path traversal attack

The fourth vulnerability affected the channel authentication cache used by guix pull and guix time-machine. These commands retrieve and authenticate Guix channel revisions.

A malicious channel definition could include a crafted channel name containing path traversal elements. Guix could then create or overwrite files outside the intended authentication cache directory.

GNU Guix documents how users define, authenticate and update channels in its guix pull documentation.

The affected command runs with the permissions of the user who starts it. As a result, the attacker could write only to locations accessible to that user rather than automatically gaining root privileges.

• The attacker controls or influences a Guix channel definition.
• The channel uses a specially crafted name containing path traversal data.
• Guix constructs an authentication cache path from that name.
• The resulting path escapes the intended cache directory.
• The command creates or overwrites a file writable by the current user.

Guix developers assessed denial of service as the most practical impact. However, more serious consequences may become possible when an attacker can target configuration files, scripts or other content later used by trusted applications.

Running guix-daemon without root does not remove every risk

The vulnerabilities affect Guix installations regardless of whether guix-daemon runs as root. Reducing the daemon’s privileges limits the files an attacker can access, but it does not correct the underlying security problems.

A non-root daemon may still modify package data, corrupt user-accessible files or expose information readable by its service account. The channel path traversal issue also runs under the account executing guix pull or guix time-machine.

Administrators should therefore install the fixes instead of treating an unprivileged daemon as a complete mitigation.

Configuration	Likely impact
guix-daemon running as root	Possible modification or disclosure of sensitive system files
guix-daemon running as an unprivileged user	Impact limited to files and data accessible to that account
guix pull run by a normal user	Path traversal can affect files writable by that user
guix pull run with elevated privileges	Channel cache issue may reach more sensitive locations

Guix users should update the client and daemon

Guix developers fixed the vulnerabilities in a series of commits merged through pull request 9665.

The project identifies commit 897832f374dcdc9eeaf19d01e70b9a92fccfc68c as the minimum corrected revision. Systems using a later commit should also include the security changes.

Administrators must update both the Guix client and guix-daemon. Updating only command-line tools while leaving an older daemon running may leave substitute-related vulnerabilities exposed.

1. Check the Guix revision installed on every affected system.
2. Update to commit 897832f374dcdc9eeaf19d01e70b9a92fccfc68c or later.
3. Restart guix-daemon after installing the corrected version.
4. Confirm that the running daemon uses the updated executable.
5. Review configured substitute servers, signing keys and discovery settings.
6. Inspect recent Guix activity for unexpected file writes or substitute errors.

Systems that use containers, build farms or several Guix daemon hosts may require separate updates. Administrators should verify each running daemon rather than checking only the workstation used to run Guix commands.

Using no-substitutes can reduce exposure during the update

Administrators concerned about downloading an update through a potentially malicious substitute source can temporarily disable substitutes while performing the upgrade.

The –no-substitutes option instructs Guix to build required items locally instead of downloading prebuilt substitutes. This removes the vulnerable remote substitute path during the update process.

Local builds may take considerable time and require substantial computing resources. Administrators must weigh that operational cost against the risk posed by configured substitute servers.

• Use –no-substitutes when the trustworthiness of available servers remains uncertain.
• Remove unknown or unnecessary substitute URLs.
• Disable automatic substitute discovery on sensitive systems.
• Confirm the public keys associated with every authorized substitute source.
• Restore substitute access only after the daemon runs a fixed revision.

Disabling substitutes does not address the separate channel path traversal issue. Users still need an updated Guix version before processing channel files obtained from untrusted sources.

Organizations should review previous substitute activity

Updating prevents future exploitation, but it does not identify files that an attacker may have modified before the fix.

Administrators should review logs and filesystem changes associated with guix-daemon, especially when systems used third-party substitute servers or automatic discovery.

Unexpected writes outside /gnu/store, unexplained changes to privileged files and unusual substitute verification errors require further investigation.

• Changes to /etc/passwd, /etc/shadow or privileged configuration files
• New startup scripts, service definitions or scheduled tasks
• Files written outside expected Guix store locations
• Unexpected substitute URLs or signing keys
• Narinfo parsing errors involving local file URLs
• Unusual channel authentication cache paths
• Package downgrades or unexplained store item substitutions

Security teams should preserve relevant logs before restarting or rebuilding affected systems. A clean reinstall may remove evidence needed to determine whether an attacker exploited the flaws.

Guix provides a checker for vulnerable installations

Guix developers also published a Scheme-based checker that can test whether an installation remains affected by the four security issues.

Users can run the checker after updating to confirm that the installed Guix client and daemon contain the required fixes. Organizations should test every daemon host separately when several machines share Guix workloads.

The corrected code can be reviewed through the fixed Guix commit.

Guix users should not rely only on a package version string because installations can track different channel revisions. Checking the exact commit provides a more reliable way to establish whether the security patches are present.

Channel files should receive the same scrutiny as software packages

Guix channels control which package definitions and Guix revisions a system retrieves. A malicious channel can therefore influence more than a single application.

Users should accept channel files only from trusted sources and verify channel authentication information before running guix pull or guix time-machine.

The official guix pull guide explains the channel update process and available authentication controls.

1. Review every channel URL and declared introduction.
2. Avoid channel files received through unverified messages or repositories.
3. Inspect channel names for unexpected path separators or traversal sequences.
4. Run updates with the minimum privileges required.
5. Keep Guix updated before processing new channel definitions.

Running guix pull as root increases the potential damage from any file-writing vulnerability. Administrators should avoid elevated execution unless their deployment model specifically requires it.

The flaws affect a core software supply chain boundary

Guix uses signatures, hashes and reproducible builds to protect package integrity. However, these vulnerabilities show that secure metadata must remain connected to safe downloading, parsing and extraction behavior.

A correctly signed record cannot prevent exploitation when software extracts unverified content too early or fails to enforce which requested object the metadata describes.

The patched Guix revision strengthens those boundaries by addressing extraction timing, request validation, local URI handling and channel cache path construction.

Organizations using Guix should update promptly, restart their daemons and investigate any systems that previously trusted unknown substitute servers. The ability to write files with daemon privileges turns a package download weakness into a potential system compromise.

FAQ