TL;DR: A compromised update to the Rust crate onering used a build.rs script to harvest Git metadata and the latest commit diff from downstream projects, then exfiltrate it through a disguised Sentry envelope, according to Aikido. Build-time execution turns a dependency into an attack path for source code theft, not just credential harvesting.
At a glance
What this is: Aikido found that compromised Rust crate onering 1.4.1 used build-time execution to steal repository metadata and the latest commit diff from consuming projects.
Why it matters: This matters because build pipelines can expose source code even when no application function is called, forcing IAM, DevSecOps, and supply-chain teams to treat build dependencies as execution-capable inputs.
Context
Build scripts run during compilation, so a package can execute code on a developer or CI machine before the application ever ships. That makes supply-chain compromise a build-path problem, not just a runtime malware problem. In this case, the identity and access angle is indirect but real: a trusted dependency executed with the build system's permissions and reached into the consuming repository.
The risk is broader than one Rust package because the same pattern can affect any ecosystem that allows code to run during install or build. When a dependency can read repository state, it can expose source changes, internal logic, and potentially other sensitive development artefacts. For practitioners, the governance question is which dependencies are allowed to execute during trusted builds.
Key questions
Q: What breaks when a dependency can run code during build time?
A: Build-time execution breaks the assumption that dependencies are passive. A malicious package can read repository data, inspect environment variables, spawn processes, and make outbound network calls before any application logic runs. That expands the attack surface to developer machines and CI runners, where privileged source and secrets often coexist.
Q: Why does build-time exfiltration matter if no secrets are stolen?
A: Because source code and commit diffs are often the most valuable assets in a development pipeline. They can reveal unreleased features, security fixes, and design details that attackers use for follow-on compromise or competitive intelligence. Losing code from the build stage is still a material security event even without credential theft.
Q: What do security teams get wrong about package ecosystem trust?
A: They often assume trusted registries and familiar maintainers are enough to validate safety. In practice, malicious updates can still execute after installation, and the real exposure comes from what the code can reach next, especially secrets, signing keys, and deployment credentials. Trust in provenance must be matched by runtime controls and secret separation.
Q: Should teams block all build scripts to reduce supply-chain risk?
A: Not always, but they should treat build scripts as high-risk and allow them only where the dependency truly needs them. The safer pattern is to isolate builds, inspect script behaviour, and deny unnecessary network or repository access. Blanket blocking is blunt, but unreviewed execution is worse.
Technical breakdown
Why build.rs is a privileged execution point
Cargo runs build.rs scripts on the local machine during compilation, which gives the script access to the developer or CI environment before application code is even linked. That means a dependency can observe filesystem layout, environment variables, and repository context without any explicit function call from the consuming project. In supply-chain terms, this is a pre-runtime execution channel, so normal library review misses the actual attack surface. The critical issue is not that the crate exposes an API, but that the build system treats it as trusted code and executes it automatically.
Practical implication: Treat build-time scripts as executable supply-chain inputs and review them with the same scrutiny you apply to binaries.
How commit metadata and diffs become exfiltration material
The malicious script walked up from OUT_DIR to locate the consuming project root, then ran git log and git diff against that repository. Commit metadata can reveal authorship, timing, and repository structure, while the latest diff exposes the exact source changes in flight. Because the script repeats on each build, it can leak a rolling stream of code rather than a one-time snapshot. This is a distinct exfiltration pattern: the attacker does not need runtime data access if build-time access already reveals valuable source content.
Practical implication: Assume any dependency with repository access can turn build output into a source-code leakage path unless build isolation blocks it.
Why disguised telemetry makes detection harder
The payload was wrapped to resemble a Sentry envelope and sent to a Sentry ingest endpoint, which is a clever way to blend malicious traffic into normal development telemetry. Security tooling that only looks for obvious command-and-control patterns may miss a POST to a familiar observability service. This is also why outbound allow-listing alone is insufficient if the allowed domain is common in software operations. The issue is not just exfiltration, but exfiltration hidden inside a trusted operational channel.
Practical implication: Inspect build-stage outbound traffic for unexpected telemetry shapes, even when the destination domain looks legitimate.
Threat narrative
Attacker objective: Steal source code and commit data from downstream Rust projects through build-time execution.
- Entry occurred through a compromised crate version, onering 1.4.1, that was trusted by downstream builds.
- Credential harvesting was not the objective; the build script instead collected repository metadata and the latest commit diff from the consuming project.
- Impact came when the stolen content was packaged as a Sentry envelope and posted to a remote ingest endpoint, exposing source changes during each build.
Breaches seen in the wild
- TrapDoor supply chain campaign 2026: TrapDoor's 34+ malicious npm, PyPI and Crates.io packages stole developer credentials and hid instructions for AI coding assistants. No victims known.
- PyPI secrets exposure 2023: Researchers found 3,938 unique secrets in published PyPI packages, 768 still valid; a new release or yank does not remove them.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Build-time execution is now a supply-chain exfiltration control point: the attack surface is no longer limited to application runtime. If a dependency can run code during build, it can inspect repository context before any security monitoring around the finished application begins. The practical conclusion is that build isolation, script review, and provenance checks must be part of package trust decisions.
Source-code theft is a different governance problem from credential theft: many supply-chain controls are tuned to secrets, tokens, or maintainer accounts, but this case targeted the intellectual content of the repository itself. That changes the risk conversation for CI/CD because sensitive diffs, unreleased features, and proprietary implementation details can be just as valuable as credentials. Teams need to classify build-time data exposure as a primary supply-chain risk, not a side effect.
Telemetry disguise creates observability blind spots: malicious traffic that mimics crash reporting or build diagnostics can pass through normal monitoring because it looks operationally expected. This is where the boundary between security telemetry and development telemetry breaks down. Practitioners should assume that trusted observability paths can be abused as exfiltration channels unless build outputs are validated against expected behaviour.
Repository access and package trust must be governed separately: pulling a crate from crates.io or directly from GitHub does not change the underlying execution risk if the build script is malicious. That means source control trust, package trust, and build execution trust are three different decisions, not one. The field needs tighter separation between what is downloaded, what is executed, and what is allowed to observe the repository.
What this signals
Build-script abuse is becoming a generic supply-chain pattern: the important shift is not the language, it is the execution model. Any ecosystem that runs package code during build can be turned into a repository-exfiltration path if the build environment can see source material. For practitioners, the control question is which dependencies are permitted to execute with repository access.
Code exfiltration deserves its own governance category: most supply-chain programmes focus on malware insertion or secret theft, but source leakage can be just as damaging and is easier to miss because it may travel through normal telemetry channels. That means CI/CD governance needs explicit rules for build-stage data egress, not only package approval and vulnerability scanning.
Identity and access controls still matter here, but as build-path governance: the build system's permissions define how far a malicious dependency can reach inside the repository and network stack. Tighten those permissions, segment build identities, and review which service accounts can run untrusted compilation steps.
For practitioners
- Restrict build-script execution in CI Run untrusted or newly changed dependencies in isolated build environments and block build scripts from reaching repositories unless they are explicitly required.
- Review dependencies that execute during build Flag crates with build.rs files for deeper inspection, especially when the script touches git, network, or filesystem APIs.
- Monitor outbound traffic from build jobs Watch for POSTs from compilation steps to telemetry, logging, or paste-style endpoints, including legitimate services that may be abused as exfiltration channels.
- Separate source trust from registry trust Treat crates.io, direct git dependencies, and internal mirrors as different trust paths, and enforce provenance checks on each path independently.
Key takeaways
- The incident shows that a malicious dependency can turn compilation into a source-code exfiltration channel without any application call ever occurring.
- The key risk is not only malware in the package, but build-time access to repository metadata and live commit diffs.
- Teams should separate package provenance, build-script execution, and network egress controls so a trusted dependency cannot silently read and export source changes.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The build script exfiltrates repository material through a dependency trust path. |
| NHI-06 — Insecure Cloud Deployment Configurations | The malicious build path exploits environment and execution assumptions in the build system. | |
| NHI-10 — Human Use of NHI | Developers and CI identities can be abused when build-time execution inherits their access. | |
| Recommendation — Scan build-time dependencies for code paths that can leak repository data or other sensitive artefacts. Harden build environments so dependencies cannot reach unintended files, networks, or project roots. Limit human and CI access granted to build identities so package code cannot inherit broad repository permissions. | ||
| MITRE ATT&CK | TA0009;TA0010 — Collection; Exfiltration | The malicious build script collected repository data and shipped it out through network traffic. |
| Recommendation — Map build-stage data theft to collection and exfiltration tactics when tuning detections for CI/CD. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Build identities and repository access determine how far a malicious dependency can reach. |
| Recommendation — Apply PR.AA-05 to restrict build identities to the minimum repository and network access they actually need. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential and token handling in build systems determines the blast radius of compromised dependencies. |
| Recommendation — Use IA-5 to control credential lifecycle and reduce the value of any secrets exposed during build. | ||
| CIS Controls v8 | CIS-5 — Account Management | CI and build accounts are the identities that make malicious build-time access possible. |
| Recommendation — Inventory and tightly manage build and CI accounts so package execution cannot inherit excessive privileges. | ||
Key terms
- Build-Time Code Execution: Build-time code execution occurs when a package install or build process runs commands before the software is fully installed. This is risky because dependency fetches, lifecycle scripts, and helper tools can execute with developer or root privileges. It turns ordinary package management into a potential host compromise path.
- Source Code Exfiltration: Source code exfiltration is the theft of repository contents, diffs, or related development data from a build or developer environment. Attackers value it because it can reveal intellectual property, security fixes, credentials embedded in code, and future release plans.
- Build Script: A build script is code that runs as part of compiling or preparing software, often before the application itself starts. In package ecosystems, it can access the local environment, file system, and network, which makes it a high-risk execution point if a dependency is compromised.
- Supply Chain Exfiltration: The movement of stolen data through a trusted software or development path rather than a classic malware upload channel. In this pattern, the attacker abuses the build, package, or developer tool chain to carry secrets out of the environment while blending into normal workflow traffic.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org