Skip to content

Back to the catalog

Compromised Rust crate onering performs code exfiltration
aikido.devwriteup

Compromised Rust crate onering performs code exfiltration

Aikido researchers discovered that version 1.4.1 of the Rust crate 'onering' (18,000+ downloads on crates.io, also compromised at the source on the maintainer's GitHub repo) shipped a malicious build.rs build script that walks up from OUT_DIR to locate the consuming project's repository root, runs git log and git diff HEAD^ HEAD to capture the latest commit's metadata and full source diff, then exfiltrates it by disguising the payload as a Sentry crash-report envelope POSTed to a real Sentry ingest endpoint. Because build.rs executes automatically at compile time via Cargo, simply building a project that depends on the crate is enough to trigger the leak, making it a novel build-time supply-chain attack vector distinct from the npm/PyPI postinstall-hook pattern, and notable for exfiltrating source code diffs rather than credentials.

TL;DR Malicious build.rs in the Rust crate 'onering' v1.4.1 steals git commit diffs and disguises the exfiltration as legitimate Sentry telemetry traffic.
Open original ↗
Document

What it is

The Rust crate onering version 1.4.1 on crates.io (a synchronous queue/channels library, 18,000+ downloads) shipped a malicious build.rs that exfiltrates the consuming project's source code. Detected by Aikido on June 10th 2026. The maintainer's GitHub repo (cenotelie/onering) is also compromised, so git pulls are not a safe alternative.

How it works

build.rs runs automatically during any build of a dependent project — you never have to call the library. It walks up from OUT_DIR until it hits a target directory and takes its parent to find your repo root, then runs git log -n 1 for commit metadata and git diff HEAD^ HEAD for the full diff of your latest commit. The data is packaged as a fake Sentry crash envelope and POSTed with curl. Because it fires on every build, it leaks a rolling stream of each new commit's diff over time, not a single snapshot.

Preconditions / Affected

Any project that depends on onering 1.4.1 (from crates.io or the maintainer's git) and builds it. The repo must be a git checkout with at least two commits for HEAD^ to resolve. No function call from the library is required — the dependency plus a build is enough.

What to do

Remove or pin away from onering 1.4.1. Aikido flags this as a 100/100 critical malware issue; users should trigger a manual rescan rather than wait for the nightly scan. Hunt for these indicators of compromise in build/network logs:

  • Dependency onering version 1.4.1 from crates.io
  • Outbound POST to the Sentry ingest endpoint:
https://o4511539639222272.ingest.de.sentry.io/api/4511539669368912/envelope/
  • Sentry DSN public key 8197ee42c4f59c83f4cc6d48f5bae821, organization o4511539639222272, project id 4511539669368912

The disguise matters for detection: outbound traffic to a Sentry ingest URL during a build looks like ordinary crash reporting, so egress that would otherwise be flagged blends in — key your detection on the specific org/project IDs above, not just "Sentry."

Caveats

The page notes a leftover commented line // std::fs::write("data.txt", payload), suggesting the payload was tested by writing to disk before the network call was added — evidence of active development, not a second live behavior. Only version 1.4.1 is named as malicious.

Technologies named here

Techniques named here

  • Malicious build script / build-time payload execution
  • Project root discovery via OUT_DIR traversal
  • Git repository data harvesting
  • Data exfiltration disguised as telemetry
  • Software supply chain compromise

Threat actors named here

  • Unknown attacker behind onering compromise

Related in Supply Chain