GHSA-G38R-8GMR-GHRF: Malicious Code Execution via build.rs in Rust Crate mysten-metrics

The mysten-metrics package was published to the Rust crates.io registry as a malicious payload disguised as a legitimate library. The crate impersonates infrastructure components associated with the Mysten Labs ecosystem to trick developers into including it in their dependency trees. The registry maintainers removed the package after identifying its malicious behavior.

This incident represents a direct supply chain attack leveraging the Rust build process. The package contained a single version (0.1.0) and lacked any legitimate functional code or external dependencies. Its sole purpose was to execute malicious routines during the compilation phase on the developer's machine or within a continuous integration pipeline.

The vulnerability class is categorized as Embedded Malicious Code (CWE-506). Because the payload triggers automatically upon compilation, the attack requires minimal interaction from the victim beyond the initial inclusion of the dependency. The exfiltration of environment variables and configuration files presents a severe risk to organizational security.

The attack vector relies on the standard functionality of build.rs scripts within the Cargo build system. Cargo allows crate authors to include a build script to perform pre-compilation tasks such as generating bindings, compiling C code, or setting configuration flags. This script compiles and runs on the host machine before the main crate compilation begins.

When a developer executes cargo build, cargo test, or cargo check, Cargo automatically compiles the build.rs file into an executable and runs it. The executable runs with the exact same privileges as the user invoking the Cargo command. Cargo does not sandbox or restrict the system access of the build script by default.

The malicious actor abused this design by placing data exfiltration routines directly inside the build.rs file. Because the package possessed no legitimate functionality, the build script served exclusively as the payload delivery mechanism. The lack of execution boundaries allows the script to read arbitrary files and open outbound network connections without user consent or notification.

The execution of the malicious payload requires the victim to add mysten-metrics to their Cargo.toml file and run a Cargo command. Once triggered, the compiled build.rs executable scans the local environment for sensitive configuration files and credentials. Targets specifically include standard paths for SSH keys, Cargo registry tokens, and cloud provider configuration files.

After gathering local files, the script iterates through all active environment variables accessible to the build process. Environment variables frequently contain API keys, database connection strings, and continuous integration secrets. The collected data is then serialized into a JSON payload or encoded format for transmission.

The final stage of the exploit involves transmitting the gathered secrets to an external server controlled by the attacker. The script uses standard network sockets to execute an HTTP POST request containing the stolen data. The process occurs silently in the background, allowing the standard build process to fail or complete without explicitly alerting the developer to the data theft.

The impact of compiling the mysten-metrics crate is the immediate and silent compromise of the host environment. An attacker gains access to all secrets readable by the user executing the build command. This typically includes source code repository access, cloud infrastructure control, and internal network credentials.

If the crate is compiled on a developer's local workstation, the attacker obtains personal access tokens and SSH keys, enabling lateral movement into organizational repositories. If compiled within a Continuous Integration/Continuous Deployment (CI/CD) pipeline, the impact often escalates to complete infrastructure compromise. CI/CD environments routinely hold highly privileged service account credentials required for production deployments.

The exfiltration occurs instantly upon the first build attempt. There is no persistence mechanism required for the attacker to achieve their primary objective. The compromised credentials can be utilized immediately or sold to initial access brokers, making rapid incident response critical.

Organizations must assume full environment compromise if the mysten-metrics crate was downloaded and compiled. The primary remediation step requires the immediate rotation of all secrets present on the affected machine or CI/CD runner. This includes resetting cloud provider credentials, revoking SSH keys, and generating new API tokens.

Developers must remove the dependency from all Cargo.toml files and audit their Cargo.lock files to ensure no transitive inclusion occurred. Local environments require sanitization by running cargo clean and clearing the Cargo registry cache located at ~/.cargo/registry/. Security teams should review network logs for outbound connections from build machines to identify successful exfiltration events.

To prevent future supply chain compromises, development teams should implement dependency auditing tools such as cargo-audit. Organizations should also explore sandboxing local build environments and CI/CD runners to restrict outbound network access and file system reads during the compilation process.