CVE-2026-77650

This CVE exposes a structural gap in Rust's security model that the language's compile-time guarantees were never designed to address. Rust prevents memory-safety bugs at runtime, but provides zero defense against malicious code that executes during `cargo build`. The append-only-vec incident demonstrates the attack vector: a crate with a build script that registers a C2 callback executes with the same trust and privilege as any legitimate dependency—no sandbox, no audit gate, no runtime prompt. The vulnerability isn't that malicious code exists; it's that the build pipeline treats all dependencies as trusted by default. The blast radius of a successful build-time compromise dwarfs a typical runtime vulnerability. When the malicious code executes, it has access to your CI/CD secrets, signing keys, deployment credentials, and build artifacts. One compromised crate doesn't just affect users of that crate—it compromises whoever consumes the resulting binary. A single popular Rust crate can have millions of reverse dependents, making the horizontal exposure across the ecosystem's trust graph potentially catastrophic. The uncomfortable reality is that the attack surface is growing in exactly the way defenders aren't watching. Thousands of crates in the registry are effectively abandoned—one-shot experiments, half-implemented utilities, projects whose authors moved on. These crates fly under the radar precisely because no active maintainer monitors unusual commits, no community flags suspicious behavior, and no history of regular updates makes a new version stand out. Attackers aren't just exploiting trust; they're exploiting neglect. The compounding factor is remediation velocity. A CVSS 9.8 score is meaningless if the remediation window stretches eighteen months. The exposure isn't just the critical severity—it's the compounding of that severity across every day the crate remains resolvable in every project's lock file, even after disclosure. Unlike npm which has audit tools and deprecated package warnings, Rust's response to a compromised transitive dependency is a forum post. You can't force-lock a transitive dependency without a breaking change upstream, so the debt compounds in version cycles, and for genuinely abandoned crates, the remediation window may be permanently infinite. What to check: Audit your dependency tree for any crates with build scripts (`build.rs`) that you didn't explicitly add. Run `cargo tree --invert <crate-name>` to identify reverse dependents. Treat any network behavior during compilation—code generation, external fetches—as a privilege that warrants scrutiny. The viable paths forward (dependency signing, reproducible builds, build-time network sandboxing) all impose friction that the ecosystem has historically rejected, but the alternative is accepting a security model that is structurally incompatible with the ecosystem's current scale. The question isn't whether this specific crate is dangerous—it's whether the Rust ecosystem can continue accepting a build pipeline that was never designed to treat dependencies as anything other than trusted.

Reviewed through automated stages and approved by a human before publication.