Summary of the Incident
Between late February and early March 2026, attackers published five malicious Rust crates to crates.io disguised as time utility libraries. These packages executed code during installation to exfiltrate environment variables and secrets from developer machines and CI/CD pipelines.
Simultaneously, an AI-powered bot targeted GitHub Actions workflows across seven repositories, including those of Microsoft, Datadog, and Aqua Security. The bot exploited misconfigurations to execute malicious payloads and harvest secrets from workflow runs.
Both attacks aimed to steal credentials, API keys, and tokens from the software build process.
Attack Timeline
- Late February 2026: First malicious Rust crate appears on crates.io.
- Early March 2026: Four additional malicious crates published.
- March 2026: Socket researchers identify the malicious packages.
- March 2026: AI bot campaign targeting GitHub Actions workflows discovered.
The compressed timeline—all activity within a single month—suggests coordinated campaigns testing different attack vectors against CI/CD environments.
Failed or Missing Controls
Lack of Pre-Installation Package Verification: The malicious crates executed code during installation. No static analysis or monitoring detected the exfiltration logic before it ran.
Insecure Storage of Secrets: The crates targeted .env files and environment variables, a common but insecure method for storing credentials. Once executed, the code accessed plaintext secrets.
Permissive GitHub Actions Workflows: The AI bot exploited workflows with write permissions. Misconfigurations allowed external contributors to trigger workflows that could execute arbitrary code.
Missing Network Egress Controls: The malicious code transmitted stolen data to attacker-controlled endpoints without being flagged for unusual outbound connections.
No Dependency Pinning or Hash Verification: Teams installed packages without verifying cryptographic hashes or pinning to specific versions, allowing malicious versions to enter builds.
Compliance Standards Overview
PCI DSS v4.0.1 Requirement 6.3.2 mandates secure software development, including secure coding techniques to prevent vulnerabilities. This responsibility extends to dependencies in your build environment.
Requirement 8.6.3 requires multi-factor authentication for all access into the cardholder data environment. API keys and service tokens stored in environment variables bypass this control.
NIST 800-53 Rev 5 Control SA-10 requires security testing throughout the development lifecycle, including scanning dependencies for malicious code.
Control CM-7 mandates that systems provide only essential capabilities. GitHub Actions workflows with write permissions to all repository contents violate this principle.
ISO/IEC 27001:2022 Control 8.30 addresses security in development involving external parties. Installing third-party packages requires due diligence and security requirements for external code.
Actionable Steps for Your Team
Implement Package Verification: For Rust projects, use cargo-vet to audit dependencies before they run. For npm, enable --ignore-scripts by default and allow installation scripts only for reviewed packages.
Remove Secrets from Environment Variables: Migrate to a secrets manager like AWS Secrets Manager, HashiCorp Vault, or Azure Key Vault. Encrypt environment variables at rest and restrict access to the decryption key.
Restrict GitHub Actions Permissions: Add permissions: read-all to workflow files and grant write permissions only where required. Use pull_request_target cautiously for workflows triggered by pull requests from forks.
Deploy Network Egress Filtering: CI/CD runners should only communicate with approved registries, artifact stores, and deployment targets. Block all other outbound traffic.
Pin Dependencies with Cryptographic Hashes: In Cargo.toml, use Cargo.lock to pin versions. In package-lock.json, verify integrity hashes. In requirements.txt, use pip-tools to generate locked dependencies with hashes.
Monitor for Dependency Confusion Attacks: Implement tooling like Snyk, Socket, or Dependabot to flag typosquatting attempts and newly published packages from unknown authors.
Audit Workflows for Stored Secrets: Search GitHub Actions logs for environment variable dumps or debug output that might have logged secrets. Rotate any credentials that appear in logs.
Require Code Review for Workflow Changes: Treat .github/workflows/ as infrastructure-as-code. Changes to workflow files should undergo the same review process as production deployment scripts.
The dual threat of traditional malware and AI-powered automation targeting CI/CD environments means you must automate verification, minimize permissions, and treat any external code as potentially hostile.
