Updates

RustSec yanks sui-execution-cut after build script exfiltration attempt

RustSec removed sui-execution-cut after its build script tried to exfiltrate data during cargo build. The crate had only one release, no downstream use, and no crates.io dependencies.

Jamie Taylor··2 min read
Published
Listen to this article0:00 min
Share this article:
RustSec yanks sui-execution-cut after build script exfiltration attempt
Source: user-images.githubusercontent.com

RustSec has yanked sui-execution-cut after flagging a build script that attempted to exfiltrate data from the build machine, a reminder that a plain cargo build can become a secret-leak event before any binary ever ships. The crate was published on April 20, 2026, then landed a RustSec advisory on April 24, with only a single version ever released and no evidence of actual usage.

The security risk sits in build.rs, not in application logic. That matters because build scripts run as part of compilation, which means a suspicious package can reach into the local environment while developers think they are merely resolving dependencies. In practice, that can expose source trees, environment variables, cached credentials, CI metadata, and other machine-local secrets during a normal build step.

RustSec’s write-up makes the package look less like a conventional library and more like a targeted supply-chain lure. sui-execution-cut had no crates.io dependencies, which removes the usual ecosystem footprint that helps a package earn trust over time. Combined with the fresh publication date and the absence of downstream adoption, the profile fits the pattern of a crate that was designed to be noticed only after it had already been pulled.

The case also lands alongside the companion mysten-metrics incident, giving the episode a wider supply-chain warning rather than a one-off takedown. Two closely related crates, both newly published on April 20, both drawing RustSec advisories on April 24, and both showing minimal package history, point to a tactic that depends on speed, adjacency, and unsuspecting automation more than on long-term maintenance.

For maintainers and security teams, the immediate audit target is clear: review not only source code, but package metadata and build-time behavior. Lockfiles, registry allowlists, and CI policies that block unknown build scripts can stop a malicious crate before it ever touches production or a developer workstation. Any freshly published package with a thin dependency graph and a name that looks adjacent to a known project deserves extra scrutiny, especially when the package can run code before the first test ever starts.

The short lifespan of sui-execution-cut limited the damage, but that is the point. The ecosystem caught this one early enough to remove it, and the next suspicious build script may not be so easy to spot.

Know something we missed? Have a correction or additional information?

Submit a Tip

Never miss a story.

Get Rust Programming updates weekly. The top stories delivered to your inbox.

Free forever · Unsubscribe anytime

Discussion

More Rust Programming News