伪装数学库的 npm 包藏有加密载荷，源码仓库不能替发布包作保
SafeDep 的分析报告指出，mathmain 及关联 npm 包中存在加密加载器，特定计算输入可触发解密并执行后续代码。研究人员发现，部分关联包的公开 GitHub 源码并不包含这段逻辑。
作者：韩启明｜OC 政策与安全编辑
SafeDep 的分析报告指出，mathmain 及关联 npm 包中存在加密加载器，特定计算输入可触发解密并执行后续代码。研究人员发现，部分关联包的公开 GitHub 源码并不包含这段逻辑。
一句话结论：依赖审查需要检查实际安装的发布产物，也需要区分“包存在”“包被下载”和“载荷已经执行”。
这些包借用了数学库的外观。报告称，加载器嵌在求解流程中，正常导入或仅检查安装脚本不足以让它显露；后续分析恢复了特定触发条件，并确认解密代码具备远程命令能力。报告前半部分保留了早期未破解的过程，后半部分补充了解密结果，阅读时需要分清调查进展。
更值得开发者警惕的是产物差异：审查过的公开源码与 npm 分发内容并不一致。维护一个看起来干净的仓库，不能替每个发布版本担保。最终进入构建环境的归档文件，才是需要核验的对象。
SafeDep 同时提醒，下载计数不能证明真实安装量，更不能证明有多少系统执行过载荷；攻击者身份和具体投放目标也没有因此确定。原版 mathjs 与这些另名包应当区分，不能把仿冒包事件扩大成整个数学库生态已经被攻破。
OC 认为，这类案例适合推动几项朴素检查：核对依赖名称与引入原因，固定版本，检查锁文件和缓存中的实际包，对照研究者公布的指标开展排查。若发现匹配项，再结合运行日志与凭据暴露范围决定处置，避免把“安装过”与“必然失陷”直接画等号。
关键事实
- 研究对象：mathmain、mathsbase、math-universe 中的特定发布内容。
- 关键证据：发布包中的加载逻辑与所查公开源码存在差异。
- 未知范围：下载来源、真实执行规模与攻击者身份未由计数确定。
OC 判断
加密让恶意逻辑更难直接阅读，条件触发又让普通测试更难撞见。供应链防线因而不能只押在一种扫描方式上。版本来源、产物差异、运行权限和异常行为需要共同形成证据。
为什么重要
- 对开发者：不要仅凭仓库页面判断 npm 产物可信，名称相似也不是身份保证。
- 对企业：让依赖排查能够追到历史版本和构建缓存，而不只查询最新版本。
评论
围绕这篇文章补充信息、提出问题或分享观察。