Vulnerability RUSTSEC-2026-0418

The build script of libz-sys version <= 1.1.30 prints the full environment of the build, including any secrets it contains, to its stdout when compiled with [email protected] or later on a Unix host. This affects any build that depends on libz-sys. Cargo saves build script stdout under target/, so the values end up in anything that stores or shares the target/ directory, such as CI caches.

This is similar to the Miri issue.

Details

To decide whether to link against a system zlib, the libz-sys build script compiles a small test program with a compiler command from cc and logs it with:

println!("running {:?}", cmd);

On Unix, Debug impl for std::process::Command prints every environment variable explicitly set on the command. Before [email protected], its Tool::to_command() set only a few compiler-specific variables. Starting with [email protected] (released 2026-10-03), Tool::to_command() clears the environment and sets every variable explicitly.

Cargo parses build script stdout for cargo: directives, and stores the full output in the build directory. It also prints it with -vv.

The probe runs for a default libz-sys build, including when pkg-config finds zlib, unless one of these applies:

• the target is Windows, Android, Haiku or OpenHarmony
• static linking is requested via the static feature or LIBZ_SYS_STATIC=1
• the zlib-ng features are enabled without stock-zlib

Mitigations

Fixed in [email protected], which no longer logs the probe command.

If you cannot upgrade, here are some workarounds:

• Build with LIBZ_SYS_STATIC=1 or the static feature, which skips the probe.
• Pin cc to a release before 1.6.0 (cargo update cc --precise <version>).

Note that upgrading libz-sys does not remove values already written. If an affected build already ran with secrets in its environment, clear CI caches and stored artifacts containing its target/build directory, and consider rotating those secrets.