AI 记忆框架遭供应链投毒：MemTensor 双仓库沦陷，新型 Go 蠕虫 sckit 窃凭证、能自我复制

原创 威胁情报中心 2026-09-24 12:09 北京

npm 与 PyPI 数小时内先后投毒：MemOS 生态四个恶意版本捆绑同一套跨平台 Go 载荷 sckit，不靠安装脚本、随包正常运行即触发，扫描用户主目录凭证与私钥，并内建向 npm/PyPI 及 GitHub Actions 自我传播的能力——一只具备蠕虫特性的凭证收割器。

01 为什么盯上的是一个"AI 记忆插件"

这次事件的受害者不是普通工具库，而是大模型记忆框架 MemOS 生态的两个分发入口：

• npm 端：@memtensor/memos-cloud-openclaw-plugin，将 OpenClaw 智能体运行时接入 MemOS Cloud 记忆服务的生命周期插件，负责在智能体处理提示词前召回相关记忆、运行结束后写入记忆，同时声明了对 Clawdbot、Moltbot 运行时的集成点。
• PyPI 端：MemoryOS，MemOS 框架的 Python 包（导入名为 memos）。

攻击者看中的正是这类组件的"站位"：它们运行在一个持续经手用户输入、且天然继承宿主进程全部环境变量的进程里。在开发者工作站上，同一用户账号往往同时握有云配置、代码仓库权限、包发布令牌和应用密钥；在 CI 环境里，进程会注入任务专用的凭证。把启动器埋进插件生命周期，就等于在正常使用过程中反复获得执行机会，而正当的记忆功能照常运转，几乎不会引起察觉。

02 两小时拉锯战：投毒—洗白—再投毒

这次攻击的发布记录呈现出罕见的"交替投毒"节奏，9 月 23 日当天（UTC）npm 侧的时间线如下：

从首次投毒到 0.1.25 上线仅约 2 小时 14 分钟。恶意版本在"干净版"发布几分钟内迅速回归，说明攻击者对发布渠道有持续控制，且很可能在试探性地上线载荷、观察反馈。PyPI 侧，最后一个干净版本 2.0.33 发布于 9 月 3 日，恶意的 MemoryOS 2.0.34（wheel 与 sdist）于 9 月 23 日 05:25 上传。

体积变化是最直观的异常信号：npm 包从干净基线的约 272 KB 暴涨到 43.6 MB（0.1.25 约 43.9 MB），PyPI wheel 从 951,210 字节膨胀到 19,201,772 字节——增量几乎全部来自捆绑的六个平台原生二进制。

一个值得记录的社区细节：最早暴露此事的线索之一，是有研究者在插件仓库提交 issue（#173），指出 0.1.21 和 0.1.23 与仓库中的任何提交都对不上——"注册表里的产物无法回溯到源码"正是供应链投毒最典型的破绽。

03 初始访问：发布流水线的凭证疑云

关于攻击者如何拿到发布权限，各家机构的结论需要分开陈述：

• npm 侧：恶意版本与历史正常版本出自同一个发布账号（leason1974），但都不带 gitHead 字段——即并非通过项目 CI 工作流发布。仓库中存在引入 sckit 二进制及启动代码的提交（插件仓库 e0c1ca3，署名 "Memtensor-AI"），但没有任何分支或标签引用它。SafeDep 进一步指出，攻击者通过向发布工作流推送提交（如 9b97ec6），使 validate-release-confirmation.mjs 向 GITHUB_ENV 写入 BASH_ENV=.github/scripts/sckit-publish-bridge.sh，从而让发布任务在发布前把 npm 令牌拱手交出。
• PyPI 侧：据 SafeDep 分析，MemoryOS 2.0.34 是由 MemTensor 自己的发布工作流基于标签 v2.0.34 构建上传的，但该标签指向的是未进入主分支、未签名的提交 b52958f（署名 "MemTensor CI Review"，地址域名为 memtensor.invalid）与 41bf5c7，后者还移除了构建后端中的 register() 令牌捕获调用。
• Socket 明确表示无法确认攻击者获得两个仓库发布权限的确切途径；StepSecurity 的事件报告也记录了"恶意 npm 产物无对应仓库提交或标签"的现象。

综合可见的证据（篡改发布工具链、定向窃取发布令牌、绕开 CI 的发布记录），发布流水线凭证失陷是目前指向性最强的初始路径，但确切入口尚未盖棺定论。

04 触发方式：不靠安装脚本，靠"正常运行"

两个生态的恶意版本都没有使用 install / preinstall / postinstall 钩子——这意味着 --ignore-scripts 之类的安装期防护完全无效。载荷的启动完全寄生在包的正常运行路径上。

4.1 npm：网关启动 + 每次记忆召回

恶意版本新增 lib/sckit.js，由插件原有的 index.js 在两个时机调用 launchStageZero()：

1. OpenClaw 网关启动时：直接拉起载荷，不附带提示词；
2. 每次记忆召回时：在剥离 OpenClaw 注入前缀后，把用户提示词塞进环境变量 SCKIT_EVENT_TEXT 传给载荷——且该调用发生在"空提示词/过短提示词"校验之前，短输入照样触发。

启动方式为 detached 子进程 + 忽略标准流 + unref()，并吞掉所有异常：父进程正常退出后载荷继续后台运行，用户无感知。代码中另有一个同步变体 collectStageZero()：它清空 BASH_ENV，并把 NPM_TOKEN 或 NODE_AUTH_TOKEN 显式映射进子进程环境——虽然该函数在所检查的 index.js 中未被调用，但它与解码配置中的 channel 字段（exact-ref-one-use-NPM_TOKEN,@memtensor/memos-cloud-openclaw-plugin）相互印证，表明攻击者对 npm 发布令牌有明确兴趣。

0.1.25 还新增 lib/tls-trust.js 与内置的 145 证书公共 CA 包 .sckit/ca-roots.pem：当宿主为 Linux、未设置 SSL_CERT_FILE/SSL_CERT_DIR 且系统 CA 文件均不可读时，自动把子进程的 SSL_CERT_FILE 指向内置证书包。该机制不关闭证书校验、不改系统信任库，纯粹是为了让载荷在精简容器、极简 CI 镜像里也能顺利完成 HTTPS 外联。

4.2 PyPI：import 即触发

MemoryOS 2.0.34 在 memos/log.py 的 configure_logging() 中埋了钩子：日志配置成功后 from memos._stage0 import trigger; trigger()，异常全部吞掉。包内有 149 个模块在模块层级调用 get_logger()，而 memos/__init__.py 的常规导入链就会触达日志初始化——因此一次普通的 import memos 就足以启动载荷（PID 守卫将其限制为每进程一次），无需调用任何 API。启动器按平台选择 .sckit/<os>-<arch>/ 下的二进制，必要时 chmod 0700，以新会话、标准流重定向 /dev/null 的方式后台拉起。

05 sckit 载荷解剖：一只奔着"自我复制"去的凭证收割机

5.1 基本形态与配置

sckit 是去符号、静态链接的 Go 二进制，单平台约 7.4 MB，覆盖 darwin/linux/windows × amd64/arm64 共六个组合。npm 三个恶意版本中的二进制哈希完全一致；PyPI 侧是另一套独立构建（哈希不同），但共享同一配置模式 sckit.runtime.v1、同一 profile semi-nuclear、同一 C2 域 skyleen.fr。

启动器以 stage0 --config64 <base64> 传入内嵌 JSON 配置，关键字段包括：

• campaign_id：npm 侧 cloud-openclaw-semi-nuclear，PyPI 侧 memos-semi-nuclear；
• inventory_roots：["$HOME"]——以用户主目录为清点范围；
• state_dir：$HOME/.openclaw/.cache/runtime（npm）/ $HOME/.memos/.cache/runtime（PyPI），配置层面的状态目录（不等于已证实创建了该目录，也不构成开机持久化机制）；
• fronts：各三台 C2 前端，均在 24 位十六进制前缀路径下暴露 /config、/status、/batch 三个端点，命名暗示控制、预检、结果回传三类角色（请求方法与报文格式未能从静态分析确认）；
• not_after：npm 配置为 1792714982（2026-10-23 00:23:02 UTC），PyPI 配置为 1792724380（2026-10-23 02:59:40 UTC）——这是配置的过期值，不能当作"定时自毁开关"的证明。

5.2 凭证收割面

静态提取的正则与字符串显示，载荷的收割清单覆盖面极广：

• 云与代码托管：AWS 访问密钥（AKIA/ASIA 前缀）、GitHub 令牌（github_pat_、gho/ghp/ghu/ghs/ghr_ 系列）、GitLab 个人访问令牌（glpat-）；
• 包仓库与 AI 服务：npm 令牌（npm_）、PyPI 令牌（pypi-）、Hugging Face 令牌（hf_）；
• 基础设施与业务服务：HashiCorp Vault（hvs.）、Slack（xox 系列）、Stripe 生产密钥（sk_live_）、SendGrid（SG.）；
• 通用形态：JWT（eyJ 开头的三段式）、以及名称含 token/secret/password/private key/api key/session cookie/数据库与消息队列连接串等特征的变量赋值。

Socket 还从二进制中识别出对具体凭证文件的引用：.npmrc、.vault-token、id_ecdsa、credentials.db、access_tokens.json、stored_tokens 等；NPM_TOKEN 与 PYPI_API_TOKEN 两个环境变量被点名。需要强调的是：以上均来自静态字符串提取与配置解码，"载荷具备采集这些凭证的能力"已成立，但凭证是否成功外发并未被观测证实。

5.3 蠕虫特性：三条传播通道

本事件最危险的信号在于二进制内建的自我传播代码。载荷的 Go 模块路径为 supplychain.local/campaign/cmd/implant，其中可见 readCredentialFile、credentialsFromFile、extractJSONCredentials、recursivePublish、prepareRemoteNode、prepareRemotePython、prepareRemoteWorkflow 等函数名，以及：

• 直接发包：通过 npm publish + npm version patch 向 npm、通过 twine upload 向 PyPI，用偷来的令牌从受害者账号发布携带蠕虫的新版本——感染开发者 → 偷发布令牌 → 以其名义投毒 → 感染其下游用户，循环放大；
• GitHub Actions 植入：二进制内嵌一个 on: [push] 的工作流模板，在被控仓库的每次推送时自动执行 ./linux-amd64/sckit stage0 --config64 ...；
• 包内自执行桩：准备了 JavaScript 桩（疑似投递为 bootstrap.cjs 并挂 postinstall）与 Python 桩，用于在其他被感染仓库中拉起载荷。

5.4 针对 PyPI 发布流水线的条件化 CI 投递链

PyPI 包还携带了一组明显瞄准 MemTensor 自家发布流水线的组件，设计相当讲究：

• sdist 用内置的 sckit_poetry_build.py 替换了标准 Poetry 构建后端，其中定义的 register() 会向 GITHUB_ENV 追加 BASH_ENV=src/memos/_pypi_bridge.sh——但所检查的源码中没有任何地方调用它，仅选用该后端不等于安装/构建时会自动改环境文件；
• _pypi_bridge.sh 设置了严格的环境门槛：仅当 $0 恰为 /app/twine-upload.sh 且处于 GitHub Actions 环境、INPUT_PASSWORD 非空时才会继续，随后调用 _initial_ci_delivery.py，执行完unset 掉 INPUT_PASSWORD 与 PYPI_API_TOKEN 并 exit 0——若以 source 方式被上传 shell 加载，会直接终结该 shell 的剩余上传流程；
• _initial_ci_delivery.py 是一条带签名校验的下载链：校验目标 URL、检出 SHA 与 GitHub 运行标识，用内嵌 Ed25519 公钥验证签名索引，按哈希钉死四个下发组件——其中"emitter"的 SHA-256 与本地 linux-amd64 载荷的哈希完全一致；执行后向 /observe/<selector> 回传观测 POST，输出标记 SCKIT_CI_RESULT_V2 / SCKIT_CI_OBSERVATION_V2；全程禁用代理、拒绝重定向、五秒超时。

签名与哈希钉死约束的是"投递的正确性"，而非"下发物的善意"。上述 CI 路径的激活、凭证窃取与发布中断均未被实际观测到，属于已就绪但未必引爆的第二战场。

06 影响评估：谁需要紧张

符合以下任一条件的环境应按失陷主机处置：

• 加载过 npm 包 0.1.21 / 0.1.23 / 0.1.25 的 OpenClaw 网关主机（含开发者工作站、服务器）；
• 导入过 MemoryOS 2.0.34 的任何环境——包括只跑了测试的 CI runner 和容器，import memos 即触发；
• 依赖通过 AI 辅助工作流自动引入的场景也应纳入排查。

风险敞口按优先级排序：受影响账号 $HOME 与进程环境中可触达的包发布令牌（npm/PyPI）> 代码托管令牌（GitHub/GitLab）> 云凭证（AWS 等）> Vault/SSH/各类 SaaS 密钥；npm 侧还需额外评估中招期间通过智能体发送的提示词中是否包含敏感信息。PyPI 项目 2.0.34 目前已被 PyPI 隔离（quarantine），但 npm 恶意版本在部分报告发布时仍可下载，且 npm 的 latest 标签曾指向 0.1.25——不要依赖 latest，按版本号锁定。

07 处置与自查清单

1. 定位与清除：在 lockfile、requirements*.txt、poetry.lock、uv.lock 及 SBOM 中检索 @memtensor/memos-cloud-openclaw-plugin 与 MemoryOS；npm 锁定回 0.1.20、PyPI 锁定回 2.0.33，或直接卸载；终止运行中的 sckit 进程，删除 ~/.openclaw/.cache/runtime/ 与 ~/.memos/.cache/runtime/。
2. 轮换凭证（从干净系统操作）：优先轮换包发布令牌，其次是代码托管、云、Vault、SSH 及所有出现在 .env 或 shell 环境中的密钥。删包不等于止损——已被窃取的凭证不会因卸载而失效。
3. 封禁与回溯：封禁 skyleen.fr 及其全部子域名；回查 9 月 23 日以来的 DNS、代理与出口日志；检索进程命令行 sckit stage0 --config64、环境变量 SCKIT_EVENT_TEXT、状态目录与 CI 输出标记。
4. 评估提示词暴露（npm 侧）：排查受影响版本加载期间经智能体提交的提示词，识别其中粘贴的凭证与机密内容。
5. 审计下游动作：若受影响主机持有发布令牌，复查自己名下包近期是否有非本人发布的版本；检查仓库工作流文件是否被改动、BASH_ENV 是否被注入、是否出现 SCKIT_CI_RESULT_V2 等标记。
6. 修复发布渠道：吊销失窃的发布凭证，检查发布任务与密钥仓库，以可信源码与构建记录校验替代产物；中长期建议启用可信发布（trusted publishing）与来源证明（provenance attestation），让注册表产物必须可回溯到真实构建。

08 技术附录

8.1 MITRE ATT&CK 技术映射

注：以上映射基于公开静态分析证据。未发现操作系统级持久化机制与横向移动的实证；自我传播能力（T1195.002 的再扩散）目前为代码层面的静态证据。

8.2 失陷指标（IoC）

受影响包与版本

网络指标

文件与进程指标

SHA-256 哈希

sckit 二进制（npm 0.1.21 / 0.1.23 / 0.1.25，三版一致）：

sckit 二进制（PyPI MemoryOS 2.0.34，与 npm 构建不同）：

PyPI 分发文件：

使用提示：命中域名或哈希只能说明"发生了接触或文件存在"，不能单独证明数据外泄成功，需结合进程与网络遥测综合研判。

09 参考链接

1. StepSecurity — Sckit Supply Chain Worm Hits MemTensor npm & PyPi scopes
https://www.stepsecurity.io/blog/sckit-supply-chain-worm-hits-memtensor-npm-pypi-scopes

2. Socket — MemTensor npm and PyPI Packages Compromised in Credential-Stealing Supply Chain Attack
https://socket.dev/blog/memtensor-compromise

3. Aikido — MemTensor npm and PyPI hit by "supplychain.local" malware
https://www.aikido.dev/blog/supplychain-local-memtensor-npm-pypi

4. SafeDep — MemTensor npm and PyPI Packages Hit by a Go Worm
https://safedep.io/memtensor-sckit-worm-npm-pypi

5. The Hacker News — Compromised MemTensor Packages Deliver sckit Credential Stealer via npm and PyPI
https://thehackernews.com/2026/09/compromised-memtensor-packages-deliver.html

6. Semgrep — The AI Ecosystem Has Worms Now: Inside the MemTensor Compromise
https://semgrep.dev/blog/2026/the-ai-ecosystem-has-worms-now-inside-the-memtensor-compromise

阅读原文

跳转微信打开