Malicious Rust Packages Hit crates.io: Developer API Keys and Secrets Being Stolen

Malicious packages were published to crates.io — Rust's official package registry — in late February and early March 2026. The packages impersonate timeapi.io, a widely used time and timezone API. Their purpose is to steal developer credentials: API keys, tokens, secrets, and environment variables from developer machines and CI/CD environments.

This is a supply chain attack targeting Rust developers specifically. If you use crates.io packages in production systems or CI pipelines, you need to act now.

What Happened

The attackers published packages with names closely resembling legitimate timeapi.io client libraries. Rust's ecosystem, like npm and PyPI, has historically been targeted less frequently than JavaScript and Python registries — which may have created a false sense of safety among Rust developers.

The malicious packages contain credential harvesting logic that executes at install time or on first import. The harvesting targets:

• Environment variables (scanning for patterns matching API keys, tokens, secrets, and database credentials)
• Contents of .env files in the working directory and parent directories
• SSH keys in the user's home directory
• AWS credential files (~/.aws/credentials)
• Any file named .env, secrets.json, config.json, or credentials in the working directory tree

Harvested data is exfiltrated to attacker-controlled infrastructure over HTTPS, making the outbound traffic appear as legitimate API calls in network logs.

The crates.io security team removed the packages after disclosure. However, any developer or CI system that installed the packages before removal may have already exfiltrated credentials.

Who Is at Risk

You are at risk if any of the following are true:

• You added a timeapi.io-related crate to a Rust project in February or March 2026
• Your CI/CD pipeline runs cargo install or cargo build in an environment with secrets in environment variables
• Your development machine has .env files, AWS credentials, or SSH keys accessible in directories where you build Rust projects
• A dependency of a dependency in your Cargo.lock file was updated to a version that included malicious code

The last point is the most dangerous. You do not need to have directly installed the malicious package. If a library you depend on updated its own dependency to a compromised version during the exposure window, your next cargo update or cargo build could have pulled in the attack.

Immediate Response Steps

1. Audit your Cargo.lock files. Check all Cargo.lock files across your projects for any crates with names containing "timeapi", "time-api", or close variants. Compare against the legitimate package list on crates.io.

1. Rotate all credentials. If you built any Rust project during the February-March 2026 window, treat all secrets that were present in that environment as compromised. Rotate API keys, database passwords, cloud provider credentials, and JWT secrets immediately.

1. Check AWS CloudTrail and equivalent logs. If AWS credentials were present in affected environments, review CloudTrail logs for unusual API calls, particularly IAM operations, S3 access from unfamiliar IPs, and EC2 launches.

1. Audit CI/CD secret exposure. Review which secrets are injected as environment variables in your build pipelines. Apply least-privilege: build stages that compile code should not have access to production database credentials or deployment keys.

1. Review your SSH keys. If SSH private keys were present in affected environments, remove them from trusted lists on GitHub, GitLab, and any servers they access. Generate new keypairs.

Why This Matters Beyond Rust

Supply chain attacks on package registries are accelerating. npm has seen hundreds of malicious packages per month for years. PyPI has an active abuse problem. Now crates.io is being targeted.

Rust's reputation for safety is a technical property of the language — memory safety, no undefined behaviour, a borrow checker that prevents entire classes of bugs. It says nothing about the security of packages published to crates.io by anonymous contributors.

The attack surface is the same as every other package registry: anyone can publish, names can be typosquatted, and malicious code can be hidden in install scripts or conditional compilation blocks that only execute in specific environments.

Developer Best Practices Going Forward

Pin your dependencies. Cargo.lock should always be committed for application projects. Never run cargo update in production pipelines without reviewing what changed.

Use cargo-audit regularly. The cargo-audit tool checks your dependency tree against the RustSec advisory database. Run it in CI on every build.

Restrict secret access in build environments. Build steps should not have access to production secrets. Use separate pipeline stages with scoped credentials. Secrets needed for deployment should never be present during compilation.

Verify crate ownership before adding dependencies. Before adding any new crate, verify the publisher identity on crates.io, check download counts and update history, and search for security advisories. A crate with 10 downloads and a one-week-old publish date warrants extra scrutiny.

Enable crates.io sparse registry. The sparse protocol makes it easier to audit exactly which package versions are being fetched. Combined with checksum verification in Cargo.lock, this reduces (but does not eliminate) the risk of tampered packages.

The Rust ecosystem is not uniquely vulnerable. But Rust developers who assumed their toolchain was safer than npm are now learning that the language and the registry are different threat surfaces.