GHSA-MH23-RW7F-V5PQ: Malicious 'time-sync' Crate Exfiltrating Environment Secrets

The time-sync crate represents a malicious code injection into the Rust software supply chain, classified under CWE-506 (Embedded Malicious Code). The package was published to crates.io with a generic, plausible name intended to attract developers seeking time synchronization utilities. However, the package's primary function was not utility-based but adversarial, designed to compromise the confidentiality of the environment in which it was installed.

Unlike vulnerabilities arising from coding errors (such as buffer overflows or logic flaws), this incident involves intentional malware. The attacker leveraged the trust model of the package registry to distribute code that executes automatically during the build or runtime phase of a Rust project. The immediate removal of the crate by registry administrators limited the infection window, but the severity for affected users is critical due to the nature of the data targeted.

This incident aligns with a broader pattern of supply chain attacks targeting the Rust ecosystem, where threat actors publish packages that mimic legitimate services to harvest credentials. In this specific campaign, the malware impersonated traffic to timeapi.io to disguise the exfiltration of sensitive data as legitimate network activity.

The malicious logic embedded within time-sync focused specifically on data exfiltration. Upon execution—likely triggered via a build.rs script or during library initialization—the code performed a filesystem scan to locate .env files. These files are standard in modern development for storing configuration secrets, including database connection strings, API keys, and third-party tokens.

Once a .env file was located, the crate read its contents into memory. The exfiltration mechanism involved constructing an HTTP request to a remote server. The advisory indicates that the attacker infrastructure was configured to impersonate timeapi.io, a known time synchronization service. This choice of domain serves as a camouflage technique; network monitoring tools observing traffic to a "time API" from a package named time-sync would likely classify the traffic as benign, allowing the exfiltration to pass through egress filters unnoticed.

The attack vector relies on the execution of unverified code within the developer's trusted environment. Since Rust's cargo build process can execute arbitrary code (via build scripts) and dependencies are linked directly into the final binary, the malware runs with the same privileges as the user invoking cargo build or cargo run.

The exploitation of this vulnerability requires no active intervention from an attacker post-publication; it is a passive trap waiting for a victim to install the package. The attack lifecycle proceeds as follows:

1. Distribution: The attacker publishes time-sync to crates.io. The name is chosen to resemble legitimate functionality (typosquatting or generic naming).
2. Installation: A developer adds time-sync to their Cargo.toml dependencies, either manually or via cargo add time-sync, believing it to be a utility library.
3. Execution: When the developer runs cargo build, cargo check, or cargo run, the package is downloaded and compiled. If the malicious code is located in a build.rs script, it executes immediately during compilation. If it is in the library logic, it executes when the application initializes.
4. Exfiltration: The malware scans the project root and parent directories for .env files, captures the content, and transmits it to the attacker's server.

The prerequisite for this attack is simply the inclusion of the dependency. No specific configuration of the host application is required, other than the presence of a .env file, which is a near-universal standard in web development.

The impact of installing time-sync is Critical. The successful exfiltration of .env files typically results in the total compromise of the application's security posture. These files routinely contain:

• Cloud Credentials: AWS Access Keys, Azure Service Principals, or GCP JSON keys.
• Database Credentials: Connection strings containing usernames and passwords for production or staging databases.
• Third-Party Secrets: API keys for services like Stripe, SendGrid, Twilio, or authentication providers (Auth0, Okta).
• Application Secrets: Encryption keys, JWT signing secrets, and debug flags.

Possession of these credentials allows the attacker to pivot from the compromised developer workstation or CI/CD runner into the production infrastructure. They could potentially exfiltrate customer data, modify infrastructure, or inject further malicious code into the codebase. Although the package was removed after 50 minutes, any machine that downloaded the crate during that window must be treated as fully compromised.

The primary mitigation is the removal of the malicious package, which has already been enacted by crates.io administrators. However, for users who may have installed the package during its availability window, simply removing the dependency is insufficient.

Immediate Incident Response Steps:

1. Identify Usage: Check Cargo.lock files in all projects for the presence of time-sync. If found, the environment is compromised.
2. Rotate Credentials: Assume all secrets present in .env files on the affected machine have been stolen. Revoke and rotate every API key, database password, and secret token found in the configuration.
3. Clean Build Environment: Delete the target directory and cargo cache (~/.cargo/registry) to ensure no malicious artifacts remain.
4. Audit Dependencies: Integrate tools like cargo-audit into the CI/CD pipeline. This tool checks Cargo.lock files against the RustSec Advisory Database and would flag this package (RUSTSEC-2026-0036).

Developers should also implement strict dependency vetting processes. Avoid adding dependencies with low usage statistics, recent creation dates, or generic names without verifying the source repository and code content.