# onering crates.io teardown: a build.rs that leaked code > How malicious onering 1.4.1 reached crates.io, how its build.rs sent each build's latest commit and diff to Sentry, and whether Chainsaw refuses it on day 0. Source: https://chain305.com/teardowns/onering-crates-build-script/ --- # Teardown: the onering crates.io compromise A stolen crates.io token, and a build script that sent out your latest commit. What happened on 10 June 2026, what onering 1.4.1's build.rs sent on every build, and where Chainsaw would and would not have stopped it. By [Muhammad Zeeshan Sultan](https://chain305.com/about/#founder), founder of Chain305 · October 2026 Questions and answers ## What happened? On 10 June 2026, a malicious `onering 1.4.1` went up on crates.io with a new `build.rs` that sent the latest commit and diff of whatever project built it to an attacker-controlled Sentry project. `onering` is a small library of synchronous queues and channels. [Aikido](https://www.aikido.dev/blog/compromised-rust-crate-onering-performs-code-exfiltration) reported the release the same day. The [RustSec advisory](https://rustsec.org/advisories/RUSTSEC-2026-0175.html), RUSTSEC-2026-0175, says one malicious version was published on 10 June and removed about six hours later, and that there is no evidence the compromised version was used. None of the sources we read gives an exact publish or removal time in UTC. RustSec lists `1.4.1` as the only affected version, with no patched version. Download figures are for the crate as a whole, not for `1.4.1`. Aikido cites over 18,000 downloads on crates.io; [Corgea](https://corgea.com/research/onering-crates-build-rs-sentry-source-exfiltration) counted 18,747 in total and 706 recent when it reviewed the crate. When we checked on 30 October 2026, we found no crate named `onering` on crates.io, and the maintainer’s `cenotelie/onering` repository on GitHub returned 404. Corgea had earlier reported `1.4.1` yanked and `1.4.0` the newest version again. ## How did the attacker get in? The attacker behind the June 2026 onering compromise got in with the maintainer’s own accounts, according to Corgea. The maintainer confirmed in the public issue thread that both their GitHub account credentials and a crates.io publishing token had been compromised. The malicious `onering 1.4.1` then went up on crates.io on 10 June 2026, and RustSec says the version was removed about six hours later, with no evidence the compromised version was used. The issue thread now returns 404, so we could not read the thread ourselves. The repository was affected too. Aikido says the GitHub repository also appeared to be compromised, so taking the crate from git instead of crates.io was not a safe workaround. [SafeDep](https://safedep.io/ti/packages/crates/onering) traces the change in the repository to one commit, `45e552f5`, which adds a 74-line `build.rs` and a `uuid` build dependency to `Cargo.toml`. ## What ran at build time? The `build.rs` in `onering 1.4.1`, released 10 June 2026, ran at build time: Cargo runs a crate’s `build.rs` while compiling the crate, before any library code is called, so building a project that resolved the version was enough. Corgea notes the script ran on `cargo build`, `test`, `bench` and `check`. Aikido, Corgea and SafeDep describe the same steps: - **Found the project being built.** Starting from Cargo’s `OUT_DIR`, the script walked up to the `target` directory and took its parent as the repository root. - **Read your latest commit.** The script ran `git log -n 1` for the commit hash, author name and email, date and subject, and `git diff HEAD^ HEAD` for the full diff of the commit. - **Sent both out as a crash report.** The script packed the metadata as tags and the diff as `extra.patch` in a Sentry event, and POSTed it with `curl` to `o4511539639222272.ingest.de.sentry.io`. - **Stayed quiet.** Errors were suppressed, so a failed upload never broke the build. None of the reports describes a second stage or credential theft. The target was source code. Aikido notes a new diff leaks on every build, a rolling stream of real changes, and traffic to a Sentry ingest URL looks like ordinary crash reporting. ## Would Chainsaw have stopped it? Yes, on day 0, for builds that go through the Chainsaw proxy: `onering 1.4.1` is refused on its first download. This comes from our re-run of 58 attacks from 2026 against production Chainsaw (v0.22.118) on 19 October 2026: - **A default rule refuses it on first download.** The default policy rule “Block install scripts that fetch remote URLs” reads the crate’s `build.rs` the first time it is fetched. The script starts `curl` with `Command::new("curl")`, so the download fails and the build script never runs. - **It does not rely on the malware feed.** Chainsaw’s known-malicious feed had no record of `onering 1.4.1` at the re-run. The refusal comes from the build script alone. - **The release hold sits behind it.** Chainsaw holds new crates.io versions for 48 hours by default, measured from the crate file’s Last-Modified date. - **The rule has to be in your policy.** It is part of the default policy set. An organisation that removed it gets the hold, not the day-0 refusal. Where the onering result has limits: - **A build script that leaks without a network client.** The default rule looks for `curl`, `wget`, a shell or a network client in the build script. A `build.rs` that does harm with, say, only `git` is caught by a custom block rule on build scripts that run commands, not by the default set. - **The original file was not tested.** The re-run used a build script rebuilt from Aikido’s write-up, not the verbatim `build.rs`, which crates.io no longer serves. - **`git` dependencies.** Cargo fetches a `git =` dependency straight from the git host, not from crates.io, so a dependency on the compromised repository never passes the proxy. - **Builds that bypass the proxy.** A laptop or CI runner pointed straight at crates.io is not protected. That is why Chainsaw also gates CI, pins laptops through MDM and blocks direct registry traffic at the network. How install-time scripts are handled across registries is covered in [our guide to Maven, Go and Cargo package security](https://chain305.com/learn/maven-go-cargo-package-security/). Every attack in the re-run is on the [2026 attack coverage page](https://chain305.com/attack-coverage-2026/). ## What should you do? First check whether any build resolved `onering 1.4.1`. Run `cargo tree -i onering` in each workspace, search `Cargo.lock` files and vendored crates, and look for `onering-1.4.1.crate` under `~/.cargo/registry/cache` on every developer machine and CI runner that built Rust code on 10 June 2026. Check `git` dependencies on `cenotelie/onering` too. If found, treat the hit as a source-code exposure, not only a malware infection, as advised by Corgea: 1. **Keep the evidence.** Preserve `Cargo.lock`, Cargo caches, CI logs and egress logs before cleaning up. 2. **Work out what leaked.** List the repositories and branches built with `1.4.1`. Each build sent the latest commit’s diff and author details. 3. **Review those diffs for secrets** and rotate anything they contained. Rotation does not take back the source code itself. 4. **Search egress logs** for `o4511539639222272.ingest.de.sentry.io`, the endpoint Aikido lists. 5. **Remove the dependency.** crates.io no longer serves `onering`, so replace it, or use a copy of `1.4.0` you already hold and have checked, then clear the Cargo caches. For the next one, keep `Cargo.lock` committed and review its changes. A small crate that suddenly gains a `build.rs` and a new build dependency in a patch release is the signal this attack left. ## Sources - Aikido Security, [Compromised Rust crate onering performs code exfiltration](https://www.aikido.dev/blog/compromised-rust-crate-onering-performs-code-exfiltration), 10 June 2026. - RustSec, [RUSTSEC-2026-0175: onering 1.4.1 removed from crates.io for malicious code](https://rustsec.org/advisories/RUSTSEC-2026-0175.html), 10 June 2026, also on [OSV](https://osv.dev/vulnerability/RUSTSEC-2026-0175). - Corgea, [onering: build.rs Sentry source exfiltration](https://corgea.com/research/onering-crates-build-rs-sentry-source-exfiltration), 10 June 2026. - SafeDep, [onering threat intelligence report](https://safedep.io/ti/packages/crates/onering). One teardown per notable attack ## Get the next teardown by email What happened, the install-path angle most coverage misses, and the rule that refuses it. [Subscribe to teardowns](https://chain305.com/teardowns/) [Read what a package firewall catches →](https://chain305.com/what-is-a-package-firewall/)