As reported by The Hacker News, a supply chain attack against MemTensor packages demonstrates how CI/CD pipelines remain one of the most underappreciated attack surfaces in modern software development. The compromise of @memtensor/memos-cloud-openclaw-plugin on npm and MemoryOS on PyPI delivered a Go-based implant called sckit — a credential stealer with worm-like propagation capabilities that targeted secrets across cloud providers, source-code platforms, and developer tooling.

Threat Alert: As reported by The Hacker News, a supply chain attack against MemTensor packages demonstrates how CI/CD pipelines remain one of the most underappreciated attack surfaces in modern software development.

Why This Attack Chain Matters

The most significant detail isn't the credential harvesting itself — it's how the attacker obtained publish access. According to SafeDep's analysis, the threat actor pushed commits that triggered MemTensor's GitHub Actions release workflows, which then handed over npm and PyPI publishing tokens. This is a textbook example of why treating CI/CD runners as trusted environments is a dangerous assumption.

The attacker didn't need to phish a developer or steal an API key from a laptop. They simply submitted code to a repository whose CI pipeline was configured to expose registry credentials during the build process.
This pattern has been repeated across multiple high-profile supply chain incidents, yet many organizations still use long-lived publish tokens in GitHub Actions workflows without scoped permissions, OIDC-based federation, or secret scanning on pull requests from external contributors.

The Worm Component Changes the Threat Model

sckit's self-propagation capability elevates this beyond a single-package compromise. The implant contains templates for installing itself into new npm packages, Python packages, and GitHub Actions workflows. This means:

Why This Attack Chain Matters
Any developer machine that imported the malicious versions potentially became a launchpad for publishing additional malicious packages using stolen tokens
CI/CD jobs running in infected environments could propagate the implant into downstream build artifacts or deployment pipelines
The blast radius is unknown — SafeDep notes it's unclear whether packages beyond MemTensor have been affected

What Was Targeted

The stealer's target list reveals a developer-centric collection strategy designed to maximize lateral movement and persistence:

  • Credential files: .npmrc, .vault-token, id_ecdsa, credentials.db, access_tokens.json, stored_tokens
  • Environment variables containing tokens, API keys, private keys, session cookies, and connection strings
  • Specific services: AWS, GitHub, GitLab, npm, PyPI, Hugging Face, HashiCorp Vault, Slack, Stripe, SendGrid, and JWTs
  • C2 exfiltration to skyleen[.]fr

This breadth suggests the operators understand exactly which credentials enable further supply chain infiltration versus which are valuable for direct monetization.

Shield53 Recommendations

Immediate Actions

  • Audit dependencies: Search package-lock.json, yarn.lock, requirements.txt, and poetry.lock for @memtensor/memos-cloud-openclaw-plugin versions 0.1.21, 0.1.23, 0.1.25 and MemoryOS==2.0.34. Pin to known-clean versions (0.1.22, 0.1.24) or remove entirely
  • Hunt for compromise: Check developer workstations and CI runners for outbound connections to skyleen[.]fr and unexpected Go binaries. Review environment variable access logs if available
  • Rotate all exposed credentials: Treat any machine that ran the affected packages as fully compromised. Rotate npm tokens, PyPI tokens, AWS keys, GitHub/GitLab tokens, Vault tokens, and any service credentials found in environment variables
  • Block the C2 domain at egress firewalls and proxy infrastructure: skyleen[.]fr

Structural Hardening

  • Adopt OIDC-based publishing for npm and PyPI instead of long-lived tokens. Both registries now support trusted publisher workflows that eliminate stored credentials from CI environments
  • Restrict GitHub Actions triggers: Ensure publish workflows only run on tagged releases from protected branches, not on arbitrary pull requests or pushes. Use environment protection rules with required reviewers
  • Implement dependency provenance verification: Use tools like Sigstore, npm's provenance attestations, or PyPI's pending provenance features to verify package integrity at install time
  • Deploy runtime package monitoring: Tools like Socket, Aikido, or StepSecurity's runtime protection can detect suspicious post-install behavior before credentials are exfiltrated
  • Segment CI secrets: Never expose all registry tokens in a single workflow. Use scoped tokens with minimum required permissions and rotate regularly

This incident reinforces a uncomfortable truth: the software supply chain is only as secure as the weakest CI/CD configuration in the dependency graph. Until publishers adopt credential-free publishing and consumers verify provenance, attacks like sckit will continue to find fertile ground.