SHA-RST: The Silent Assassin in Your Cargo.toml

In the world of open-source development, names matter. We trust names like openssl, requests, and tokio. When you see a crate named sha-rst in your dependency tree, your brain likely autocorrects it to 'SHA (Secure Hash Algorithm) for Rust'. It sounds boring. It sounds foundational. It sounds safe.

That psychological blind spot is exactly what the threat actor behind sha-rst was banking on. Released on December 8, 2025, this crate wasn't a hashing library at all. It was a digital syringe loaded with credential-stealing malware, designed to slip past your mental firewall and into your build pipeline.

Unlike a typical vulnerability where a developer makes a mistake (a buffer overflow or a logic error), this was a deliberate, weaponized component. It didn't have a bug; it was the bug. It serves as a grim reminder that in the supply chain, you aren't just importing code; you're importing the author's intentions.

The brilliance of this attack wasn't the code itself—it was the delivery mechanism. The attacker didn't just upload sha-rst and hope people would download it. They used a technique known as Dependency Nesting combined with Typosquatting.

The primary lure was a crate named finch_cli_rust. This was designed to mimic the legitimate finch_cli tool. If a developer mistyped the name or was misled by a search result, they pulled in the malicious finch_cli_rust.

Here is where it gets clever. finch_cli_rust didn't contain the malicious logic directly. If a security researcher or an automated scanner glanced at the top-level crate, it might look relatively benign—perhaps just a wrapper. But inside its Cargo.toml, it defined a dependency on sha-rst. The moment cargo build resolved the tree, sha-rst was pulled in, and the trap was sprung. It's a Matryoshka doll of malice: a fake CLI hiding a fake library hiding a real exploit.

So, what did sha-rst actually do? It didn't mine crypto, and it didn't ransom files. It went for the highest-value targets on a developer's machine: identity.

Analysis by the RustSec team and researcher Matthias Zepper revealed that the crate contained code specifically designed to hunt for standard credential paths. It targeted:

• SSH Keys: ~/.ssh/id_rsa, ~/.ssh/id_ed25519
• Cloud Credentials: ~/.aws/credentials, ~/.aws/config
• Environment Variables: Scanned for strings like KEY, TOKEN, SECRET

The implementation likely utilized Rust's std::fs to recursively walk these directories and std::net (or a bundled HTTP client) to exfiltrate the data. This wasn't a complex ROP chain; it was a smash-and-grab robbery implemented in safe, stable Rust code.

The most dangerous aspect of Rust malware is the build.rs script. In Rust, a crate can define a build script that compiles and executes before the main application is built. This is intended for compiling C dependencies or generating code, but for an attacker, it's a blank check for Remote Code Execution (RCE).

While the specific execution method for sha-rst (whether it used build.rs or a runtime initializer) ensures that the malware runs automatically, the effect is immediate. You don't need to import the library in your code. You don't need to call a function. You just need to type:

cargo build

Or even just let your IDE auto-index dependencies. In the background, sha-rst compiles, executes, reads your ~/.ssh directory, and sends your private keys to an attacker-controlled endpoint. By the time the compiler finishes, your digital identity is already being sold or used to pivot into your company's infrastructure.

This crate was live for roughly 24 hours before being nuked from crates.io on December 9, 2025. It had 22 downloads. That's a small number in the grand scheme of things, but in security, we don't count downloads; we count potential impact.

If you were one of those 22 unfortunates, or if you are reading this because you found sha-rst in a legacy Cargo.lock file, there is no 'patching'. You cannot fix this. Your machine is compromised. The only remediation is a Scorched Earth policy.

Every credential on that machine is burned. Your SSH keys? Revoke them. Your AWS keys? Rotate them. Your GitHub PATs? Delete them. The persistence of the attacker is unknown, so the safest path is to wipe the machine and start over. This is the cost of a single typo in a modern development environment.