Developers who installed specific MemTensor packages from npm or PyPI on 23 September should treat affected systems as potentially compromised after malicious releases were found delivering a cross-platform credential stealer known as sckit.

Security researchers reported that attackers compromised legitimate MemTensor package distribution channels and inserted a Go-based payload targeting Windows, Linux and macOS. The affected releases include versions 0.1.21, 0.1.23 and 0.1.25 of the npm package @memtensor/memos-cloud-openclaw-plugin and PyPI package MemoryOS version 2.0.34.

The incident is significant because package-manager compromises can reach developer laptops, CI runners and other environments that often contain valuable source-control, cloud and registry credentials.

Key takeaways

  • Three malicious npm releases and one PyPI release have been identified in the MemTensor incident.
  • The sckit payload is a Go-based credential stealer with Windows, Linux and macOS variants.
  • Researchers say it targets developer, cloud, registry and source-code credentials, among other sensitive data.
  • Anyone who executed an affected package should treat the host as potentially compromised rather than relying only on uninstalling the package.
  • Credential rotation should be performed from a known-clean system after affected hosts are isolated and investigated.

Which package versions were affected?

SafeDep's reconstruction of registry and repository events shows malicious npm versions alternating with clean releases during the early hours of 23 September. Version 0.1.21 was published with the sckit binary, 0.1.22 was clean, 0.1.23 was malicious, 0.1.24 was clean and 0.1.25 was malicious.

At 05:25 UTC, according to SafeDep's timeline, MemoryOS 2.0.34 was uploaded to PyPI after repository and tag activity associated with the compromised release.

The alternating clean and malicious releases make version-level checking important. Teams should inspect package-lock files, dependency manifests, build logs and caches rather than assuming that every installation of the package family was affected.

What sckit is designed to steal

Security analyses describe sckit as a cross-platform credential-stealing implant written in Go. The malware searches for secrets useful in developer and cloud environments, including source-code access, package-registry credentials and cloud authentication material.

The Hacker News reported that the implant targets credentials and data associated with cloud, registry, source-code and developer tooling. The risk is therefore broader than the compromised package itself: stolen tokens can potentially provide access to additional systems after the original machine has been cleaned.

That is why removing the malicious dependency alone is not sufficient remediation if the payload executed.

Why developer environments are valuable targets

Developer workstations and CI systems sit close to software supply chains. They may have permission to clone private repositories, publish packages, access cloud infrastructure or retrieve deployment secrets. A credential stealer running in that environment can therefore create opportunities for further compromise.

AI-agent and developer-tool ecosystems add another layer of sensitive information. Agent configuration, prompts, integration tokens and local environment files may expose details that attackers can use to move into other services.

This incident also demonstrates why package provenance matters. A package can have a legitimate name and history while a particular release is malicious if the publisher account, repository workflow or release process is compromised.

What affected developers should do

First, identify whether an affected version was installed or executed. Check dependency lock files, package-manager logs, CI histories, container layers and build caches for the known malicious versions.

If an affected release executed, isolate the host from sensitive networks and preserve relevant logs for investigation. Security teams should look for suspicious processes, persistence mechanisms and outbound connections associated with the payload.

Credentials accessible from the affected environment should be considered exposed. Rotate source-control tokens, npm or PyPI publishing credentials, cloud keys, CI secrets and other relevant authentication material from a known-clean system. Where possible, revoke existing tokens before issuing replacements.

Review access logs for those credentials to identify suspicious activity after the package was installed. Organisations should also invalidate sessions and rotate secrets that may have been stored in environment variables, configuration files or developer credential stores.

How to reduce package supply-chain risk

Teams can reduce exposure by pinning dependencies, reviewing lock-file changes, restricting automatic upgrades in sensitive environments and using package-security scanning before new versions enter production or CI systems.

Publishing credentials should use the narrowest possible permissions and short lifetimes where supported. CI jobs should not automatically inherit broad cloud or source-control credentials unless the task requires them.

Organisations should also maintain an inventory of where developer and build secrets are stored. That makes emergency rotation faster when a dependency compromise occurs.

Sources and current status

SafeDep documented the release timeline using GitHub events, commit metadata and npm/PyPI registry APIs. The Hacker News independently reported the compromise and sckit's cross-platform credential-stealing behaviour. Because supply-chain investigations can develop quickly, affected teams should continue checking package registries and security advisories for updated indicators and remediation guidance.