Teardown: the onering crates.io compromise

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 reported the release the same day.

The RustSec advisory, 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 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 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. Every attack in the re-run is on the 2026 attack coverage page.

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, 10 June 2026.
• RustSec, RUSTSEC-2026-0175: onering 1.4.1 removed from crates.io for malicious code, 10 June 2026, also on OSV.
• Corgea, onering: build.rs Sentry source exfiltration, 10 June 2026.
• SafeDep, onering threat intelligence report.