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.
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.
> libz-sys build script leaks environment variables in the build directory
| Details | |
| ------------------- | ---------------------------------------------- |
| Package | `libz-sys` |
| Version | `1.1.29` |
| URL | [https://github.com/rust-lang/libz-sys/pull/280](https://github.com/rust-lang/libz-sys/pull/280) |
| Date | 2026-10-28 |
| Patched versions | `>=1.1.31` |
| Unaffected versions | `<1.0.21` |
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](https://blog.rust-lang.org/2026/09/21/github-actions-leaking-secrets-when-miri-output-is-cached/).
## 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::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](https://doc.rust-lang.org/nightly/cargo/reference/build-cache.html#build-cache),
and consider rotating those secrets.
See [advisory page](https://rustsec.org/advisories/RUSTSEC-2026-0418.html) for additional details.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
libz-sys1.1.29>=1.1.31<1.0.21The build script of
libz-sysversion <= 1.1.30 prints the full environmentof the build, including any secrets it contains, to its stdout when compiled
with
cc@1.6.0or later on a Unix host. This affects any build that depends onlibz-sys. Cargo saves build script stdout undertarget/, so the values endup 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-sysbuild scriptcompiles a small test program with a compiler command from
ccand logs itwith:
On Unix,
Debugimpl forstd::process::Commandprints every environmentvariable explicitly set on the command. Before
cc@1.6.0, itsTool::to_command()set only a few compiler-specific variables. Starting withcc@1.6.0(released 2026-10-03),Tool::to_command()clears the environmentand sets every variable explicitly.
Cargo parses build script stdout for
cargo:directives, and stores the fulloutput in the build directory. It also prints it with
-vv.The probe runs for a default
libz-sysbuild, including when pkg-config findszlib, unless one of these applies:
staticfeature orLIBZ_SYS_STATIC=1zlib-ngfeatures are enabled withoutstock-zlibMitigations
Fixed in
libz-sys@1.1.31, which no longer logs the probe command.If you cannot upgrade, here are some workarounds:
LIBZ_SYS_STATIC=1or thestaticfeature, which skips the probe.ccto a release before 1.6.0 (cargo update cc --precise <version>).Note that upgrading
libz-sysdoes not remove values already written. If anaffected build already ran with secrets in its environment, clear CI caches and
stored artifacts containing its
target/build directory,
and consider rotating those secrets.
See advisory page for additional details.