npm 包的发布（原帖）。关于最近发生的一些工具链攻击的闲聊

Aluria

微信 OpenClaw 接口封装: `@aluria/wechat-ai-api`

基于微信 OpenClaw 开放接口规范封装的 Node.js SDK。为开发者提供标准化的 API，用于快速接入微信扫码鉴权、长轮询消息监听、以及富媒体（文本、图片、文件、视频、语音）的自动化收发。

🔗 GitHub 仓库: https://github.com/Wu-Yijun/wechat-ai-api

Aluria

@aluria/wechat-ai-api

首次运行需要微信扫码登录获取凭证, 你的聊天列表会多出一个 OpenClaw. (图中我给他改名成通知入口了)

后续就可以靠几行简单的代码实现这样的效果: Image description

import { WeChatApi } from "@aluria/wechat-ai-api";
const bot = new WeChatApi();
await bot.login(); // 首次扫码登录
bot.startPolling(); // 启动消息监听
bot.on("text", async (msg) => {
  console.log("收到文字消息:", msg.text);
  await bot.messages.sendText("你刚才说了: " + msg.text);
});

复杂的代码我就不展示了, 后面就是水一水论坛, 关于微信OpenClaw的接口和发布 npm 的事

Aluria

微信 OpenClaw 接口

虽然腾讯赶着吃龙虾也没吃上热乎的, 但终归是弄出了一个对接 OpenClaw 的接口. OpenClaw 我没有, 目前也不准备装, 但是, 既然 openclaw 能用, 凭什么我不能用!

本着不浪费的原则, 我在被灰度测试开放这个接口的当天(2026/3/28), 就研究了一下官方的npm库: weixin-openclaw-cli. 这是用来在已有 openclaw 的环境下安装微信消息接口插件的库, 核心是 weixin-openclaw 这个库, 用来收发消息.
但不幸的是, 底层的这个库同样是针对性的, 必须要从 openclaw 环境提供一些凭证, 然后直接从openclaw对象中提取.
我的目的是使用最小的依赖(甚至0依赖)去实现同样的消息收发, 所以我只能分析它的代码, 从中找出请求格式和数据结构.

虽然 weixin-openclaw 没有提供 github 仓库, 但是, 它们的 npm 库是未经构建的原始代码, 我只需要 npm pack 下载到本地, 解压即可分析.
更令我惊喜的是, 包内采用了 MIT 开源协议, 也就是我可以放心的逆向出接口并打包为原生调用, 并发布到网上公开使用.

阅读接口函数后可以发现:

它们的核心大概是从自己的屎山代码库中直接搬运出来的, 里三层外三层的套娃, 每一层几乎就是把参数换个结构再传给下一层.
这套与 openclaw 接口耦合的代码大概是 AI 写的, 它们可能自己都不知道自己的逻辑和调用关系: 一些函数悬空导出毫无作用; 函数重复利用度也低的令人发指, 明明只是多传一个控制参数的事, 却分散在了不同的文件中使用不同的实现, 然后再套一层壳分情况讨论.
没有一点欲望去改写它的代码, 全部函数和逻辑都简化并重写才能令人心情愉悦.

然后我就重写了一套结构, 将微信消息接口, 消息发送, 消息解析, 数据服务接口, 数据编码加密, 语音格式转化, 这些功能分别形成类, 降低相互的耦合性, 通过调用的形式整合到主类 WeChatApi 中.
最终用大约 1500 行代码加 300 行注释重构全链路. 全程只依赖 node:fs node:crypto fetch 等运行时, 没有任何额外依赖, 除了唯一引入的外部库是 silk-wasm.
这使我非常不爽, 是因为微信的语音是通过一种非常特殊的格式SILK发送的, 我们需要解码为 WAV, 但是只有两套路径: 使用 C ffi, 引用一个最后更新是10年前的SILK仓库, 或者用预编译的 wasm 方案. 无奈之下, 我将 silk-wasm 改为了动态导入, 理论上只要你不关心语音消息也是可以不安装任何依赖, 纯享原生JS/TS.

关于如何引用回复消息, 我没调出来, 要么是腾讯官方的库中就没有实现好, 要么就是接口不支持.

Aluria

这是腾讯官方库的npmjs上的作者列表, 猜猜哪个是真大佬 ( )

发现一个好玩的事

明显, 这套代码很草台班子, 比如, AI生成, 人工核查不足. 比如, 这个团队明显是临时新组建的, 名下没有任何的其它项目. 还比如, 项目框架采用了默认的MIT协议, 尽管似乎它们并没有想开源, 但还是把源码直接放出来的. (我们下一节关于如何发npm还会提到这点).

真正搞笑的是, 看看它们一股脑打包上传的文件中的更新日志吧:
Image description

项目的更新日志告诉我们, 原则上更新需要写日志, 但你连它的默认模板都没动过.......

Aluria

Aluria 尽管似乎它们并没有想开源, 但还是把源码直接放出来的.

哈哈，迅速 callback 了。 ~~看看真正的大公司腾讯吧，什么叫做开源精神~~

不管腾讯有没有想开源，claude code 反正是被迫“开源”了，起因是没有将 dist/index.js.map放进 .npmignore
源码打包的产物 index.js 通常是高度压缩且混淆的，而 .map文件则提供了这份精简代码到源码函数具体文件具体位置的一一映射（其大小可能比源码还大）

理论上，可以通过线性复杂度的无启发式函数执行将.map还原为原始代码，这能否算作直接开源呢？

愚人节冷笑话：
Anthropic 只有两种选择：

要么所有被 claude code 支持的接口全部弃用，需要更新各种产品才能正常使用
要么 claude code 成为笑话，随便一个工具都能伪造它调用它的 API

曾经 opencode 被迫放弃 claude 相关接口（律师函警告），现在一报还一报了

Aluria

如何发布 npm 仓库

我曾一直以为这是个很严肃很复杂的问题, 但直到真正尝试后才发现, 也就那么回事......

$ $
但这却在为我们敲响警钟: 不要去轻易信任一个看似开源的 npm 仓库, 因为发布实在是太随意了, 没有人会花时间去看一眼它的源码
最近两天的一次供应链攻击, 不也是这样吗——直到病毒出了bug导致崩溃, 才让安全专家无意中查看了一下源码, 才警觉npm库已经被篡改了.

言归正传

npm 库发表分三步

注册账号: 随便一个邮箱就可以注册 (注册的人没那么多, 像是我的 aluria 就没被简短的随机字符账号占用, 多么美好的一天啊)
登录账号: 我是说, 在终端中登录你的账号
发布项目: 还是终端中一行命令

注册账号

访问官网注册 https://www.npmjs.com/signup
这没啥说的, 注册完需要到设置里开启 2FA 认证, 这是发布公开项目的必要条件.

登录账号

通常, 使用 npm login 即可, 如果你曾配置过淘宝/清华镜像, 需要指定源:

npm login --registry=https://registry.npmjs.org/

发布项目

在你已经有一个完整的项目后, 使用下面的命令发布公开库(同样使用--registry=指定源). 流程都是自动的, 一键完成.

npm publish --access public --registry=https://registry.npmjs.org/

配置项目

这才是最重要的, 如果你不想把你的测试文件, 密钥缓存文件之类的东西都一股脑传上去的话......

首先是 package.json, 这不用我多说, 但凡用了npm库就会有它. 与通常的不用发表的项目不同, 里面有几项需要注意的:

name: 最重要的, 你可以通过 @scope/package-name 发布作用域包（Scoped Package）, 这似乎是目前比较推荐的方式(避免包名冲突). 作用域必须是你的账户名或组织名, 所以注册账号前可以先想一想你到底叫啥.
version: 同样需要注意, 你更新库时需要改变版本号, 否则会发布失败(我没试过减少会怎么样, 但估计是可以的, 只要不重名就行)
repository: 你的 git 仓库, 这会在 npmjs 页面侧边栏显示它的链接
files: 很重要, 通过它去指定你仅要上传哪些文件/文件夹, 而不是全部文件.
- 此外你可以通过配置 .npmignore 决定不去上传哪些文件(具体配置我后面会写)
main 和 types: 指示你的入口文件和类型定义是什么, 别人导入你的库是从哪导入的 (基本上现代的打包工具都会创建到这个位置)
scripts.build: 构建脚本是什么, 比如 tsc 比如 tsup 比如 deno bundle. 很有意思的时, npm 怕你发布更新时忘记构更新你的最终构建, 于是会先尝试执行 npm run build 打包.
- tsc 会导致你的 import {xxx} from "./xxx.ts" 报错, 因为它只接受 .js 文件导入, 你需要用 .js 的形式导入你的 ts 文件, 这对现代开发模式很不友好, 因此我选择 tsup.

一个节选的版本, 列出了一些需要关注的项

{
  "name": "@aluria/wechat-ai-api",
  "version": "1.0.1",
  "repository": {
    "type": "git",
    "url": "https://github.com/Wu-Yijun/wechat-ai-api.git"
  },
  "main": "dist/index.js",
  "types": "dist/index.d.ts",
  "files": [ "dist" ],
  "scripts": {
    "build": "tsup",
  }
}

关于需要发布哪些文件, 跳过哪些文件

基本上是仅需要上传最小量的文件:

/dist/index.js     # 打包好的单文件脚本
/dist/index.d.ts   # 类型标注, 方便使用者获得编辑器高亮和语法检查
/dist/index.js.map # 不见得需要, 这是打包后产生的调试信息, 方便使用者debug时映射位置
/package.json      # 对 npm 来说, 你的全部配置信息都在里边
/readme.md         # npmjs 上展示的页面, 你写的越明白, 别人越可能去用
/LICENSE           # 许可证

而以下是一个可以参考的 .npmignore 配置

# ⚠️ 你已经打包了, 不用再上传源文件
src/
example/
# 临时文件不用
temp/
# 📌 你的机密及缓存绝对不要传上去
session.json
.env
# 构建/调试用到的配置文件, 别人也不需要
tsconfig.json
tsup.config.ts
.eslintrc*
.prettierrc*
# 你的编辑器配置, 日志, 调试信息
.vscode/
.idea/
*.log
npm-debug.log*
yarn-debug.log*
yarn-error.log*

更简单的办法

其实这个时代, 这些问题直接问 AI 就好, 你可以先打印文件结构(手动删掉输出的 node_modules 下的文件夹结构), 再和你的 package.json 一块丢给 AI. 你就直接问它你的 package.json 怎么配置, 你的 .npmignore 怎么写, 就行了.....

tree /F  # windows
tree     # linux

Aluria

Aluria 我曾一直以为这是个很严肃很复杂的问题, 但直到真正尝试后才发现, 也就那么回事......

但这却在为我们敲响警钟: 不要去轻易信任一个看似开源的 npm 仓库, 因为发布实在是太随意了, 没有人会花时间去看一眼它的源码

轮番callback了，应该是3月30号，npm的基础设施级包 axios 被投毒，已导致众多受害者。
攻击者为axios添加了一个新的依赖 X，起初它是安全无毒的，随后上传更新后的 X，其中包含了post install代码会创建脚本从网络下载病毒，病毒运行后再删除脚本和post install 安装痕迹。
最终，病毒会默默扫描你的电脑，把你所有的密码凭证.env等打包发到服务器上......

究极简单的手法，但是杀伤力巨大。。。。。

吓得我赶紧满电脑找了一下我没有该版本的axios，又好好回忆了一下github actions没在本地放什么机密

Aluria

Aluria npm的基础设施级包 axios 被投毒

哈哈，我就知道。我用的是 npm install axios 而不是 nmp ci，这样默认安装的是最新版本，因此，尽管供应链攻击只持续了三个小时，但是我的脚本（Github Action 自动监视人文讲座）每小时至少运行一次，所以，很不幸，中招了......

Image description

不过好在，泄露的最多只有sep账号密码，且我周四已经花了一晚上把我所有账号密码都改了一遍。
此外，ucas邮箱与sep密码相互独立，目前应该是无风险了

Aluria

Microsoft 发布关于此次攻击的详细分析: Axios npm supply chain compromise

创建一个一级标题, 因为话题比较独立:

关于防范供应链投毒的实用策略与一些奇技淫巧

在包管理工具（如 NPM）全面完善其权限管控体系之前，开源库的供应链投毒风险将持续存在。不仅是 Node.js 的 NPM，Python (PyPI)、Rust (Crates) 或 Go 环境下的第三方库也都面临相同的安全威胁。本文将以 NPM 为例，简要探讨如何在不同运行环境下增强项目的安全性。

引入第三方库并运行的场景主要分为两类：本地开发环境与持续集成环境（如 GitHub Actions 运行器）。

1. 本地环境：安全性与便利性的矛盾

风险分析

在本地直接运行恶意依赖包的风险较高且破坏性大。本地恶意脚本（如利用 postinstall 钩子自动执行的代码）一旦触发，由于具有与当前用户相同的系统权限，可以轻易常驻系统建立后门、静默扫描本地文件系统以窃取私钥或环境变量等机密数据。虽然 Windows Defender 或自带的杀毒软件能提供一定的防护拦截，但难以完全防范专门针对开发者环境编写的脚本。

防御策略

本地防护的难点在于难以同时兼顾安全性和开发便利性。如果追求绝对安全，在虚拟机或 Docker 容器中进行隔离开发能有效限制恶意代码的破坏范围和数据窃取能力，但这也使得项目的日常运行变得极其繁琐。在常规的物理机开发流程中，可以采取以下策略降低风险：

延迟更新与锁定版本： 对于高频使用的流行库，其安全性受到社区的广泛监督。一旦出现恶意代码（例如近期的投毒事件在三小时内即被阻断），通常会被迅速发现并通报。因此，只要避免安装刚刚发布的最新版本，并在安装库时通过指定确切的版本号（或利用锁版本文件）进行严格控制，即可大幅降低中招概率。

限制安装脚本执行： 执行安装命令时，附加 --ignore-scripts 参数可以阻止安装阶段自动运行脚本，使大量依赖此机制的恶意代码无法被触发。

  # 设置 npm 包的最小发布时间为 30 天，避免安装过于新的包，这些包没有经过充分的社区审查，存在安全风险
  npm config set min-release-age=30
  # 安装 npm 包, 使用 --ignore-scripts 禁用生命周期脚本(postinstall)，避免安装过程中执行恶意代码
  npm install --ignore-scripts axios

考虑更换受限的运行时： 可以尝试使用具有细粒度权限控制的运行器，如 Deno。Deno 默认需要对每一次的文件读写、网络请求进行显式授权，从底层架构上提升了安全性，不过这会带来一定的生态兼容问题和操作上的繁琐。

2. CI/CD 环境： GitHub Actions 的防护

风险分析

与本地环境不同，GitHub Actions 通常是临时且隔离的运行器。恶意脚本在此类环境中的破坏范围有限，其主要目的是窃取当前 CI/CD 流程中注入的少量密钥或凭据。然而除了 NPM 包，GitHub Actions 调用的第三方 Action 脚本本身也存在投毒风险。

防御策略

严格执行 CI 专有命令： 在工作流中只使用 npm ci 进行依赖安装。它会严格依据 package-lock.json 安装完全一致的依赖树，避免因为版本号的动态匹配引入未经测试的恶意版本，保持环境一致性。
锁定 Action 版本（Commit Hash）： 采用指定的 Commit Hash 替代分支名来引用第三方库，以确保运行的确切代码不会被篡改。缺点是配置不够简洁且无法获取后续的维护更新。
强化机密信息的传递安全：避免将密钥以明文形式写入到运行器磁盘的文件中。不要在 Bash 脚本中直接使用 ${{ secrets.XXX }} 语法注入数据，这会带来严重的命令注入攻击风险。

利用管道传递密钥(我觉得不好)：尽量不要通过 env 块将其提供给环境变量。恶意代码可以轻易通过遍历 process.env 获取所有环境变量。相反，你可以配置 shell: bash {0}，并使用标准输入stdin和管道操作，将密钥直接从内存传递给 Node.js 进程（例如通过管道输入后在 Node.js 中读取 stdin），从而完全避开环境变量的暴露风险。

- name: Run script with line-break secrets
    env:
      TOKEN_A: ${{ secrets.TOKEN_A }}
      TOKEN_B: ${{ secrets.TOKEN_B }}
    # BAD: run node myscript.js
    # Better:
    shell: bash {0}
    # 使用 \n 换行符拼接
    run: |
      echo -e "$TOKEN_A\n$TOKEN_B" | node myscript.js

import * as fs from 'fs';
// 1. 读取并按换行符分割
const stdinData = fs.readFileSync(0, 'utf-8').trim();
const [tokenA, tokenB] = stdinData.split(/\r?\n/);
// 此时必须依赖严格的顺序
console.log('Token A length:', tokenA.length);

限制网络出站请求（Egress Filtering）： 恶意脚本窃取机密后必须通过网络发送至外部服务器。可以在工作流的最前端引入网络配置库（如 step-security/harden-runner）。
初始阶段可以先设置其以 audit（审计）模式运行数次，记录正常的构建过程需要访问哪些域名；随后将其配置更改为 block（拦截）模式，仅允许白名单内的目标网络被访问。这样即使恶意脚本成功读取了环境中的机密，也无法将有效信息外传。
建议不要在 Bash 脚本中直接使用 ${{ secrets.XXX }} 语法注入数据，这会带来严重的命令注入攻击风险。

如上图所示，工具会生成运行阶段的网络报告，我们可以直接在 recommendations 中找到对应的白名单配置建议。更多细节见下一章

3. 增加攻击成本的一些 (奇技淫巧) 非标技巧

以下方法无法防御高级别的定向攻击或底层网络监听，但在面对结构简单、基于自动化特征匹配的恶意脚本时，能有效增加攻击者的获取难度。

规避自动化静态扫描

在本地环境中，开发者通常将测试所需的配置信息保存在 .env 或 .pem 文件中。多数用于广撒网的恶意脚本会优先全盘扫描这些具有固定扩展名特征的机密文件。
为了防范这种简单的特征扫描，可以直接修改这些配置文件的后缀名。例如，将其重命名为 .so（Linux 系统下的动态链接库后缀）。通用脚本为了执行效率通常会跳过体积较大且被认为是二进制格式的文件。而在 Node.js 中，依然可以通过 node --env-file=.so 正常加载该配置。只要脚本没有执行深度文本内容扫描，这种方式就能避开初级的安全风险。

环境变量数据混淆

在 GitHub Actions 等环境中，密钥通常会被直接注入到脚本的 process.env 中。如果恶意脚本直接获取并遍历打印所有的环境变量，明文密钥就会泄露。
我们可以对存入 GitHub Secrets 的数据增加掩码或混淆操作。例如，通过一个预设的字符串（如 123456abc）对原始密钥进行异或编码后存储。这样，即使恶意脚本拿到了 process.env 中的全部内容，只要它没有进一步逆向分析你的业务代码，就无法得知真实密钥的解码逻辑。
注意： 这种方式仅能防范单纯的环境变量提取，如果恶意脚本直接 Hook 了网络请求模块获取请求 Headers 数据，由于密钥在此阶段已还原为明文，依然存在数据泄露的风险。但对应没有网络请求的自动化脚本，已经是完全够用的，恶意脚通常是无法访问内存数据的。

严格限制单步运行时间

恶意脚本执行额外的指令（如遍历文件、打包数据、发起网络请求）需要消耗时间。在 GitHub Actions 单核运行器上，这种窃密行为会导致运行耗时显著增加（往往是正常时间的数倍）。通过为关键步骤设置严格的 timeout-minutes，一旦超时立即强制中断，能有效阻断一些耗时较长的恶意收集行为。

Aluria

对比一下带病毒的与不带病毒的运行结果, 明显能发现前者运行时间非常长, 暗示病毒在后台收集敏感信息......
Image description

此外, 还多安装了一个 npm 包, 也就是病毒来源 plain-crypto-js

关于 `step-security/harden-runner` 的使用

这似乎是一个较为轻量化的包, 能快速设置网络规则, 尽管功能不是很完善, 有少量bug, 但可以让安全性上一个台阶

具体使用分为两个阶段, 审计阶段和规则模式

jobs:
  job-name:
    runs-on: ubuntu-latest
    steps:
      # Enable Network traffics rules
      - name: Harden Runner
        # 通过确保 name@hash 脚本本身稳定安全
        uses: step-security/harden-runner@fa2e9d605c4eeb9fcad4c99c224cee0c6c7f3594 # v2.16.0
        with:
          egress-policy: audit # audit 为审计模式, block 为规则模式

首先, 什么也不用配置, 多跑几次工作流, 确保覆盖到全部情况. 此时, 脚本会监视每一个网络请求, 并自动创建报告.

你可以在 Summary 中看到信息, 并通过链接查看详情.
Image description

在对应的网站中, 会统计每一次运行访问到的域名, 并推荐一个规则列表:
Image description

理论上复制进去替换就行, 你也可以主动检查每一个域名和端口, 并进行调整, 可以使用类似的 *.domain.com 通配符匹配所有子域名, 但存在一些小问题(DNS解析不全, redirect 直接走 ip 可能会被拦截, 因此推荐完整域名).

除此之外, 还有一些小设置可以调整:

      - name: Harden Runner
        uses: step-security/harden-runner@fa2e9d605c4eeb9fcad4c99c224cee0c6c7f3594 # v2.16.0
        with:
          egress-policy: block # 规则模式
          # 禁用遥测 (不会发送数据给网站, 因此最终看不到拦截结果)
          disable-telemetry: true
          # 不监视文件变化 (没啥用)
          disable-file-monitoring: true
          # 注意是管道符号 `>` , 每一行的字符串以空格隔开! 因此不允许注释和空格(源码中也是直接 `.split(" ")` 分割每条规则)
          allowed-endpoints: >
            api.github.com:443
            cdn.jsdelivr.net:443

此次病毒分析

参见:
https://securitylabs.datadoghq.com/articles/axios-npm-supply-chain-compromise/#block-known-malicious-packages-with-scfw (讲的很好, 还有源码)
https://www.trendmicro.com/fr_fr/research/26/c/axios-npm-package-compromised.html

plain-crypto-js@4.2.1 是 crypto-js@4.2.0 的一个克隆版本，其 package.json 文件中新增了一个 scripts 块:

-   "name": "crypto-js",
-   "version": "4.2.0",
+   "name": "plain-crypto-js",
+   "version": "4.2.1",
    "description": "JavaScript library of crypto standards.",
    "main": "index.js",
+   "scripts": {
+     "test": "echo \"Error: no test specified\" && exit 1",
+     "postinstall": "node setup.js"
+   },
    "dependencies": {},

其中的 "postinstall" 钩子会在安装完成后自动被调用, 而恶意代码就藏在其中. 似乎虽然第三方安全审核没过, 但是你直接 npm install 时可不管这个. (应对方法就是 npm config set min-release-age=10 设置安全缓冲时间, 或禁用安装后的钩子 npm install --ignore-scripts axios )

这次攻击的脚本倒是没太多可圈可点的地方(常规操作), 但是时间线上有几个细节很有意思:

时间线(UTC)	事件	亮点说明
Mar 30, 23:59	包含恶意脚本的 plain-crypto-js@4.2.1 被发布	选择了一个很巧妙的时间, 发布完进入00:00, 这是定时任务的高发时间, 导致大量任务堆积而扫描不及时
Mar 31, 00:05	npm 安全扫描器自动将 plain-crypto-js 标记为恶意软件
Mar 31, 00:21	引用了该库的恶意版本 axios@1.14.1 由被盗用的 jasonsaayman 账户发布
Mar 31, 01:38	Axios 维护者 DigitalBrainJS 提交了 PR #10591，为受损版本添加弃用警告。	维护者试图阻止用户安装最新新版本, 加入npm警告
Mar 31, 01:42	PR #10591 合并到主分支	还有人正好看到警告, 在PR中问怎么回事
Mar 31, 02:19	Ashish Kurmi（StepSecurity）在 issue #10597 报告了安全漏洞。该 issue 随后被jasonsaayman 账户删除	*哈哈, 开始斗法了*
Mar 31, 02:19	Ashish Kurmi 在 issue #10601 再次报告了安全漏洞。该 issue 随后被 jasonsaayman 账户删除	*issue 编号到了5位数, 是因为hacker一直用脚本创建 issue, 试图掩人耳目, 让维护者看不见真正的问题.*
Mar 31, 03:00	Ashish Kurmi 在 issue #10604 再次报告了安全漏洞。	应该是攻击结束, 骇客跑路了
Mar 31, 03:25	姗姗来迟的 npm 收到问题报告, 删除了 `plain-crypto-js` 库

后续就是慢慢走流程了.

总体而言, 作为一个开源项目, 这次事件中 axios 维护者反应是相当及时的, 至少不是所有人都睡死过去了, ~~但恐怕当天晚上有不少人没机会睡觉了......~~