Does Cargo run code from dependencies through build.rs?

Yes. A crate can ship a build.rs file, and Cargo compiles it and runs it just before building that crate. Because dependencies are crates too, a dependency's build script can run on your machine during cargo build. It runs with your user's permissions, with no sandbox.

What the Cargo documentation says

The Cargo reference describes a build script as a build.rs file in a package root. It is meant for work Cargo cannot do alone, such as compiling bundled C code, finding system libraries or generating Rust code.

Key lines from the reference:

• Just before a package is built, Cargo compiles the build script into an executable and runs it.
• It is rebuilt if its source files or dependencies change.
• Scripts should not modify files outside OUT_DIR.

That last line is guidance for authors. It is a convention, not an enforced sandbox, so a hostile script can ignore it.

Why this is a supply chain concern

Think about when this runs. You add a crate, run a build, and arbitrary code from that crate has already executed, before any of your tests. The same pattern applies to procedural macros, which also run code at compile time, though the page we fetched covers only build scripts.

Malicious crates in the wild are discussed in our posts on typosquatting and malicious crates on crates.io. The build script is one place that code can hide.

How to review a build script quickly

1. List the crates in your lockfile that have a build script. Look in each crate's source for a build.rs.
2. Read the file. Legitimate scripts compile C code, probe for libraries or set cfg flags. Be suspicious of network calls, reads of environment variables and writes outside the output directory.
3. Compare the crate's published source with its repository. A script that appears only in the published package deserves a closer look.
4. Prefer crates with a short, readable script over crates that build a lot at compile time.

How to limit the exposure

• Build in a clean container or CI runner with no deploy keys or cloud credentials in the environment.
• Keep the lockfile committed so new versions do not arrive silently.
• Cache vetted dependencies in a vendored or mirrored source, and review changes to it.

Environment variables are the usual loot. A build that has nothing sensitive to steal limits the damage even if a script misbehaves.

Quick check

Safeguard does SBOM and dependency scanning for Rust projects, and a free scan lists every crate you pull in.

Sources

• Cargo book: build scripts

Last reviewed: 19 October 2026.