GHSA-8p3x-q3q3-q3v5

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:

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::to_command() set only a few compiler-specific variables. Starting with
cc@1.6.0 (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 libz-sys@1.1.31, 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.