The compromise of legitimate MemTensor packages across both npm and the Python Package Index (PyPI) highlights a particularly dangerous form of software supply-chain attack: malicious code being distributed through software that developers already trust.
On September 23, 2026, researchers identified malicious releases affecting MemTensor's MemOS, an open-source memory framework designed for large language models and AI agents.
The affected packages were:
@memtensor/memos-cloud-openclaw-pluginversions 0.1.21, 0.1.23 and 0.1.25MemoryOSversion 2.0.34
The malicious releases contained a previously undocumented Go-based implant called sckit, compiled for Windows, Linux and macOS across both x64 and ARM64 architectures.
The objective was not merely to compromise the application using MemTensor.
The malware was designed to search developer environments for valuable credentials, API tokens, SSH keys and other secrets that could potentially enable additional attacks.
Why this incident is particularly serious
There is an important difference between a malicious package created by an unknown attacker and a legitimate package that has been compromised.
Developers frequently treat established packages differently because they have:
- recognizable project names;
- legitimate source repositories;
- previous clean releases;
- real maintainers;
- existing community adoption; and
- prior inclusion in trusted projects.
All of those signals normally increase confidence.
In this case, that trust became the attack vector.
The malicious releases were published under the same package identities developers were already using, meaning a normal package update could introduce the attacker's code without requiring a developer to install an unfamiliar dependency.
The attack affected both JavaScript and Python ecosystems
The compromise is also noteworthy because it crossed package ecosystems.
The npm package:
@memtensor/memos-cloud-openclaw-plugin
was compromised alongside the PyPI package:
MemoryOS
This matters because many modern AI development environments combine Python-based model frameworks with JavaScript or TypeScript orchestration and application components.
An attacker compromising both package channels increases the potential reach across developer workstations, AI applications, build environments and CI/CD pipelines.
It also demonstrates that organizations should avoid treating npm security and PyPI security as separate problems.
They are part of the same software supply chain.
Malicious releases were mixed with clean versions
One particularly interesting detail is the release pattern.
The malicious npm versions were:
0.1.21
0.1.23
0.1.25
But versions:
0.1.22
and
0.1.24
were reportedly clean and largely matched the last known-good release.
This alternating pattern is unusual.
It may complicate detection because simply observing that later versions exist does not mean every version after the initial compromise contains the malicious payload.
The last known-good npm release identified by Socket was:
0.1.20
For PyPI, the last known-good release was:
MemoryOS 2.0.33
while:
2.0.34
contained the malicious implant.
This reinforces an important supply-chain lesson:
Version numbers alone do not establish trust.
Organizations need the ability to identify exactly which package version was installed and when.
The malware executes automatically
The attack does not depend on a developer manually launching an obviously suspicious executable.
The compromised packages themselves launch sckit.
In the npm package, the malicious code executes when the OpenClaw gateway starts and again when a memory-recall operation occurs.
During the memory-recall event, the user's prompt text is also passed to the malicious executable.
In the PyPI package, the implant launches when the memos Python module is imported.
That means simply running:
import memos
in an affected Python environment could be enough to activate the malware.
For npm users, normal plugin functionality could trigger execution.
This is what makes package supply-chain compromises so dangerous.
The malicious action is hidden inside expected application behavior.
sckit is cross-platform by design
The packages contain versions of sckit for:
- Windows x64
- Windows ARM64
- Linux x64
- Linux ARM64
- macOS x64
- macOS ARM64
This indicates that the attackers were not interested in one narrow operating environment.
The implant was designed to follow developers wherever they worked.
That is especially relevant for AI development teams, which commonly use combinations of:
- macOS developer laptops;
- Linux workstations;
- cloud development environments;
- Docker containers;
- CI/CD runners; and
- Windows development systems.
An attacker targeting the development ecosystem cannot assume one operating system anymore.
The malware reflects that reality.
The real target was developer secrets
Static analysis of the sckit binaries identified searches for credential files and environment variables associated with a wide range of services.
The targeted secrets reportedly include:
- npm tokens;
- PyPI tokens;
- GitHub tokens;
- GitLab credentials;
- AWS access keys;
- HashiCorp Vault tokens;
- SSH private keys;
- Hugging Face tokens;
- Slack credentials;
- Stripe keys;
- SendGrid credentials;
- JWTs;
- database connection strings; and
- other API keys and passwords.
The malware also searches for files including:
.npmrc
.vault-token
id_ecdsa
credentials.db
access_tokens.json
and
stored_tokens.
This tells us something important about the attacker's objective.
The compromised package itself may be only the first stage.
The real value lies in credentials that allow the attacker to move into other systems.
Developer machines are credential-rich targets
Modern developer environments frequently contain considerably more privileged information than ordinary employee endpoints.
A developer laptop may hold access to:
- source-code repositories;
- cloud environments;
- container registries;
- package registries;
- production APIs;
- testing environments;
- CI/CD systems; and
- secrets-management platforms.
This means compromising a developer dependency can potentially provide an attacker with an entire collection of credentials in one place.
Developers often need this access legitimately.
Attackers understand that.
That makes software-development environments highly attractive targets.
CI/CD systems may be even more valuable
If the compromised packages were executed inside automated build pipelines, the risk could be substantially greater.
CI/CD environments routinely expose temporary or persistent secrets to build jobs.
These can include:
- package-publishing tokens;
- cloud credentials;
- deployment keys;
- signing credentials;
- GitHub or GitLab tokens; and
- infrastructure-management secrets.
A malicious dependency running inside such an environment may therefore inherit access far beyond the application it belongs to.
Organizations should not assume that a build runner is harmless simply because it is ephemeral.
If the runner exposes powerful secrets during execution, a few seconds may be sufficient for malware to extract them.
The package may also have captured AI prompts
The npm compromise introduces another interesting dimension.
According to Socket's analysis, the malicious plugin invokes sckit during memory recall and passes the user's prompt text to the malicious process.
This means organizations using the affected OpenClaw plugin should consider whether AI prompts processed while the malicious package was active may have been exposed.
That is particularly relevant for enterprises using AI agents with internal information.
Prompts may contain:
- source code;
- internal documentation;
- customer information;
- credentials pasted accidentally;
- business strategy;
- security configuration; or
- proprietary research.
AI supply-chain security therefore introduces a new category of exposure.
The attacker may not only steal machine credentials.
They may gain visibility into the information humans and agents exchange.
The malicious code appeared in source-control commits
Socket found that the malicious additions also appeared in commits associated with MemTensor repositories.
The malicious plugin commit was authored as:
Memtensor-AI
while the MemOS commit appeared under:
MemTensor CI Review
Both commits introduced the sckit binaries and launcher functionality.
However, no active branch or tag reportedly referenced those commits at the time of Socket's analysis.
This adds another layer to the incident.
The attacker apparently interacted not only with package publication mechanisms but with the project's source-control environment.
However, researchers had not yet established precisely how the threat actor gained publishing or repository access.
That uncertainty should be preserved.
It would be premature to conclude exactly which credential or maintainer account was compromised until the investigation establishes the initial access mechanism.
The npm packages were not published through the normal CI workflow
Socket identified another useful clue.
The malicious npm releases were published from the same account used for previous legitimate releases, but lacked a gitHead field normally associated with the project's release process.
Researchers therefore concluded that the affected releases were not published through the normal CI workflow.
This demonstrates why package provenance matters.
A package may carry the correct project name and publisher identity while still being released through an unexpected mechanism.
Organizations increasingly need controls that answer not only:
“Who published this package?”
but also:
“How was this package built and from which source commit?”
The malware reports to skyleen.fr infrastructure
The implanted binaries were configured to communicate with command-and-control infrastructure under:
skyleen[.]fr
Multiple unique subdomains were configured for the npm and PyPI campaigns.
The malware searches the user's home directory and environment for secrets before reporting information back to attacker-controlled infrastructure.
Security teams should immediately review DNS, firewall and proxy telemetry for connections to this domain and its subdomains beginning September 23, 2026.
However, as always, domain blocking alone is insufficient.
Once infrastructure becomes public, attackers can replace it quickly.
There are signs of possible package-republication capability
Strings recovered from the binary include functionality related to package manifests and repository files.
Researchers believe this may suggest the malware can potentially use stolen registry credentials to republish additional packages.
This possibility is especially concerning.
If malware steals an npm or PyPI publishing token and subsequently uses that token to compromise another legitimate package, the attack can become self-propagating through developer ecosystems.
We have already seen how registry-native attacks such as Shai-Hulud can turn package credentials into mechanisms for further supply-chain compromise.
At present, Socket describes this as suggestive functionality rather than confirmed widespread worm behavior in the MemTensor incident.
That distinction matters.
But defenders should treat stolen publishing credentials as particularly urgent.
What organizations should do immediately
Any environment that installed or loaded one of the affected versions should be treated as potentially compromised.
Affected npm versions are:
@memtensor/memos-cloud-openclaw-plugin@0.1.21
@memtensor/memos-cloud-openclaw-plugin@0.1.23
@memtensor/memos-cloud-openclaw-plugin@0.1.25
Affected PyPI version:
MemoryOS==2.0.34
Organizations should identify these versions across:
- package-lock files;
- npm lockfiles;
- requirements files;
- Poetry lockfiles;
- uv lockfiles;
- container images;
- SBOMs;
- CI/CD logs; and
- developer systems.
Socket recommends pinning npm environments to 0.1.20 and Python environments to 2.0.33, or removing the affected packages until a verified clean release becomes available.
Removing the package is not enough
This is perhaps the most important operational point.
Once the malicious package has executed, uninstalling it does not magically revoke credentials already collected by the malware.
Affected organizations should assume that secrets accessible from the relevant home directory or process environment may have been exposed.
That means rotating potentially reachable:
- npm tokens;
- PyPI publishing tokens;
- GitHub credentials;
- GitLab tokens;
- AWS credentials;
- Vault tokens;
- SSH keys;
- Hugging Face tokens;
- Slack keys;
- Stripe keys;
- SendGrid credentials; and
- application or database secrets.
Security teams should also review their own package registries for unexpected releases if publishing credentials were present on affected hosts.
Hunt for sckit artifacts
Organizations should search for running processes named:
sckit
and investigate the package-specific runtime directories identified by researchers, including:
~/.openclaw/.cache/runtime/
and:
~/.memos/.cache/runtime/
These artifacts should be preserved if forensic investigation is required before removal.
Organizations should also review endpoint telemetry for unusual detached Go binaries launched from package directories or cache locations.
Why this matters particularly for AI development
The compromise deserves attention beyond the immediate MemTensor user base because it illustrates how rapidly AI development ecosystems are becoming part of the software supply-chain attack surface.
AI frameworks increasingly interact with:
- external APIs;
- cloud credentials;
- vector databases;
- memory systems;
- source repositories;
- developer tools;
- messaging platforms; and
- autonomous agents.
Plugins and supporting libraries therefore operate in environments rich with credentials and sensitive information.
Attackers do not necessarily need to compromise the underlying AI model.
Compromising one trusted integration around the model may be substantially easier.
AI agent plugins deserve special scrutiny
Agent ecosystems create another security challenge.
Traditional software dependencies usually run when an application launches or executes specific code.
Agent plugins may be invoked continuously as the agent:
- remembers information;
- retrieves context;
- calls tools;
- processes prompts;
- interacts with APIs; or
- performs autonomous tasks.
That means a compromised plugin may gain repeated access to user input and the surrounding runtime environment.
The MemTensor incident demonstrates why agent plugins should be treated as executable supply-chain dependencies rather than harmless feature extensions.
Software provenance is becoming essential
This incident reinforces the need for verifiable package provenance.
Organizations should increasingly ask:
- Did the package come from the expected repository?
- Was it built from a verifiable commit?
- Was the release produced through the expected CI workflow?
- Does the artifact match its source code?
- Has the package suddenly added native binaries?
- Has its size changed dramatically?
- Has its runtime behavior changed unexpectedly?
The compromised PyPI package provides a particularly obvious clue.
MemoryOS 2.0.34 was approximately 19.2 MB, compared with roughly 951 KB for version 2.0.33.
That enormous increase came from the bundled sckit binaries.
Package-size anomalies like this can provide valuable automated detection opportunities.
Native binaries inside language packages deserve attention
Both affected packages included precompiled native Go binaries.
That creates another useful defensive rule.
JavaScript or Python packages that suddenly introduce:
- PE executables;
- ELF binaries;
- Mach-O files; or
- platform-specific native payloads
should receive additional scrutiny, particularly if previous releases contained none.
Native binaries are not inherently malicious.
Many legitimate packages require them.
But unexpected native components dramatically increase the range of actions a package can perform.
The broader cybersecurity lesson
The MemTensor compromise brings together several trends that security teams need to watch carefully:
trusted package compromise + npm and PyPI distribution + cross-platform malware + credential theft + AI-agent integration + potential prompt exposure + possible registry credential propagation.
The most important lesson is that software supply-chain security cannot stop at checking whether a package name looks legitimate.
In this case, the package was legitimate.
The trust relationship itself had been compromised.
That means organizations need to move toward a model where dependencies are continuously verified based on provenance, release behavior, code changes and runtime activity.
AI development makes this even more important because these environments frequently combine powerful credentials with software capable of autonomously communicating with external services.
The package manager has effectively become part of the enterprise security perimeter.
When a trusted package update can execute a cross-platform credential stealer on developer machines and CI systems, dependency management is no longer merely a developer concern.
It is an incident-response, identity-security and supply-chain-security problem.
And in the MemTensor case, organizations that executed the malicious releases should treat credential rotation as seriously as package removal, because once sckit has run, the dependency itself may be gone while the secrets it collected remain useful to the attacker.

Unknown threat actors have managed to compromise two legitimate MemTensor packages across the npm and Python Package Index (PyPI) repositories to push a platform-specific Go-based implant dubbed sckit designed for Windows, Linux, and macOS. According to reports from Aikido, SafeDep, Socket, and StepSecurity, the libraries in question below - @memtensor/memos-cloud-openclaw-plugin versions
Source: Compromised MemTensor Packages Deliver sckit Credential Stealer via npm and PyPI via The Hacker News — published 23 Sep 2026.
Was this article helpful?
Your feedback helps us improve the knowledge base.