GHSA-8p3x-q3q3-q3v5: libz-sys build script leaks environment variables in the build directory

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 cc@1.6.0 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:

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

On Unix, Debug impl for std::process::Command prints every environment variable explicitly set on the command. Before cc@1.6.0, its Tool::tocommand() set only a few compiler-specific variables. Starting with cc@1.6.0 (released 2026-10-03), Tool::tocommand() 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 LIBZSYSSTATIC=1 the zlib-ng features are enabled without stock-zlib

Mitigations

Fixed in libz-sys@1.1.31, which no longer logs the probe command.

If you cannot upgrade, here are some workarounds:

Build with LIBZSYSSTATIC=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.