GHSA-8p3x-q3q3-q3v5 json
libz-sys build script leaks environment variables in the build directory
published 17d ago modified 16d ago also RUSTSEC-2026-0418
- cvss
- —
- not scored
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- —
- no score, EPSS covers CVEs only
- public exploits
- 0
- none known
Summary
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.
Patch / fix
Is GHSA-8p3x-q3q3-q3v5 in your dependencies? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.
Check with FencerAffected packages
| ecosystem | package | affected | fixed in |
|---|---|---|---|
| crates.io | libz-sys | >=1.0.21, <1.1.31 |
1.1.31 |
References
Sources
Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.