arrayref EUVD-2026-63780

Triggering requires that a target project actually declares or transitively resolves arrayref 0.3.10 and then compiles it (running cargo build, cargo test, or any build that invokes the crate's build script/proc-macro), and that the build host has outbound network access to reach the command-and-control server. Limiting factors: exploitation is confined to the specific malicious version 0.3.10 (unaffected versions do not trigger it), it fires only at build/compile time rather than in a shipped running service, it depends on the victim adding or already depending on the crate (effective user interaction), and egress-filtered or air-gapped build environments blunt the C2 callback even if the code executes.

The input CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N, C:H/I:H/A:H = 9.8) overstates the true access model: exploitation is not a remote unauthenticated network hit against a running service but requires a victim to add and compile the poisoned crate, which is functionally user interaction (UI:R). Despite that nuance, real-world risk is high because the affected version is confirmed weaponized malware documented by the Rust project blog, StepSecurity, SafeDep, and RustSec - the technical impact is total (full code execution on build/CI infrastructure) and it is trivially automatable once the crate is in a dependency tree. No EPSS score, SSVC decision, or CISA KEV entry was provided in the input, so quantitative exploitation-probability signals are missing; however, the qualitative evidence of an active, disclosed supply-chain attack should override the absence of those scores. Treat as an urgent priority for any Rust shop, while noting the impact is scoped to environments that actually built with 0.3.10.

An attacker publishes the trojaned arrayref 0.3.10 to crates.io; a developer or CI system resolves it as a direct or transitive dependency and runs cargo build. The malicious build-time dependency executes automatically during compilation, calls out to the attacker's C2 server, and grants arbitrary command execution on the build host - allowing credential theft, lateral movement, or poisoning of produced binaries. This is not a theoretical POC: the malicious code is the crate itself as documented by the Rust Security Response team.