Sckit Supply Chain Worm Hits MemTensor npm & PyPi scopes

What it is

"Sckit" is a credential-harvesting worm found in malicious releases of the npm package @memtensor/memos-cloud-openclaw-plugin, a legitimate MemOS Cloud memory integration for the OpenClaw agent runtime (also declares Clawdbot/Moltbot integration points). Malicious versions are 0.1.21, 0.1.23, and 0.1.25, published September 23, 2026 (UTC). Each bundles Go executables that harvest secrets from the host. A related PyPI artifact MemoryOS==2.0.34 is reported but was not independently validated by this investigation.

How it works

The malicious versions add no install/preinstall/postinstall script. Instead they import launchStageZero from a new file lib/sckit.js and call it from the plugin's existing lifecycle: once at gateway startup (no prompt), and again on every memory-recall event — where it passes the user's prompt text (after stripping an OpenClaw-injected prefix) via SCKIT_EVENT_TEXT. Both calls copy process.env into the child, so any credentials in the gateway environment reach the payload.

The launcher resolves a binary under .sckit/<platform>-<architecture>/ (mapping Node's x64 to amd64, using sckit.exe on Windows), then spawns it detached with stage0 --config64 <base64 config>, stdio: "ignore", and unref() — suppressing output without persisting across reboot. There is no rate-limit or once-only guard, so each recall re-launches. Six binaries cover Linux/macOS/Windows × AMD64/ARM64; hashes match across all three versions. The decoded config uses schema sckit.runtime.v1, campaign cloud-openclaw-semi-nuclear, sets inventory_roots: ["$HOME"], state_dir: $HOME/.openclaw/.cache/runtime, and names three external fronts with /config, /status, /batch paths (control/preflight/results, roles inferred). Expiry field not_after: 1792714982 = 2026-10-23 00:23:02 UTC.

0.1.25 adds lib/tls-trust.js plus a bundled .sckit/ca-roots.pem (145 certs). Only on Linux, when no SSL_CERT_FILE/SSL_CERT_DIR is set and no system CA file is readable, it points SSL_CERT_FILE at the bundled roots — helping HTTPS succeed in minimal containers. It does not disable verification or touch the system trust store.

A telling signal: unpacked size jumps from ~272 KB (clean) to ~43.6 MB (first malicious) and ~43.9 MB (0.1.25), driven by the native binaries. Malicious releases reappeared within minutes of two clean restorations — indicating retained unauthorized publishing access, not a one-off push. npm artifacts exist with no matching repo commits/tags, pointing to a compromised publishing path.

What to do

• Treat any host that loaded and exercised these plugin versions as exposed — a scripts-disabled install still executes on plugin use.
• Do not just republish clean contents: revoke unauthorized publishing access and audit the release environment, since malicious versions returned minutes after cleanup.
• Review permissions and activity of every affected npm/registry token.
• Rotate credentials reachable from the agent's process environment (cloud config, source repos, publishing tokens, app secrets) — scope extends beyond the memory service.
• Check for .sckit/ directories and $HOME/.openclaw/.cache/runtime; correlate the three config/status/batch endpoints against network logs.

Caveats

The reproduced JavaScript only launches the binary; it does not itself publish packages, upload Python distributions, or modify GitHub workflows — propagation and successful exfiltration require binary or telemetry analysis to confirm. A separate function collectStageZero() (which clears BASH_ENV, maps NPM_TOKEN/NODE_AUTH_TOKEN, 15s timeout) is not on the active call path. Config field roles and the expiry timestamp are name-based inferences, not proven enforcement. The size anomaly in the sibling @memtensor/memos-local-openclaw-plugin was attributed to legitimate native-binding changes. A blocked domain lookup shows contact attempted, not data exfiltrated. Story is still developing.