一款已从 Open VSX 下架的恶意扩展，至今仍能从 TRAE IDE 的扩展市场下载。该扩展冒充常见的 Solidity 语言支持插件，包名为 juannegro.solidity。截至 2026 年 7 月 18 日，TRAE 的插件市场 API 依然提供该扩展的 0.0.189 版本（VSIX 文件）。

逆向分析显示，该扩展实际是一个跨平台(Windows、macOS、Linux) 的恶意程序投递器(dropper)。它会在 IDE 启动后自动运行，在系统中创建用户级别的自启动项，然后通过以太坊智能合约获取后续恶意代码的下载地址，或者直接连接远程控制 Shell 的地址。

VSIX 文件只负责首次投放，而 C2（命令与控制）配置信息存储在区块链上，可以随时更改。攻击者不必重新发布扩展，只需修改合约中的参数，就能将所有已感染主机指向新的后端服务器。

一、背景

最早公开此事件的是 X 用户 @Will42W。2026 年 7 月 17 日，他发文提醒 TRAE IDE 用户注意扩展供应链风险，并在推文中 @ SlowMist 安全团队。他指出，TRAE 会快速同步 Open VSX 上新上架的扩展，但不会同步 Open VSX 后续下架或拉黑的风险扩展。

慢雾(SlowMist) 安全团队随后与 Will42W 沟通，确认该问题扩展为 juannegro.solidity。我们接着检查了 TRAE 市场，并分析了 VSIX 文件、各平台载荷、持久化方式以及以太坊上的合约配置，最终确认攻击者在该扩展发布后仍通过区块链交易动态更换后端地址。

https://x.com/Will42W/status/2077938237704958154

MistEye 响应

MistEye 是由 SlowMist 自主研发的 Web3 威胁情报与动态安全监控系统，集成了安全监控与情报聚合能力，为用户提供实时的风险预警与资产守护。

MistEye 已第一时间通过情报推送与客户告警通道同步风险。

二、恶意扩展分析

2.1 仿冒正版 Solidity 扩展

该扩展的发布者名为 juannegro，仿冒了 Juan Blanco 开发的官方 Solidity 扩展，直接抄袭了后者的描述、图标和代码仓库信息。juannegro 与正版发布者 juanblanco 只差几个字母，用户极易看走眼。

根据 Will 提供的信息和 Open VSX 的官方记录，该扩展于 2026 年 5 月 1 日上架，数小时后就被发现并下架。目前 Open VSX 的 API 查询会返回“未找到该扩展”，但截至 7 月 18 日，TRAE 仍然能搜索并下载 juannegro.solidity@0.0.189。

我们两次复查发现，TRAE 提供的可下载版本始终为 0.0.189，其内部版本时间戳也停留在 5 月 1 日。唯一变化的是扩展信息页的“最后更新时间”字段，但这并不表示攻击者上传了新文件，只是元数据刷新而已。

2.2 恶意扩展自动激活启动

扩展的 package.json 声明了两个激活事件：

onLanguage:solidity 会在用户打开 Solidity 文件时激活扩展，但更危险的是 onStartupFinished。根据 VS Code 扩展 API 文档，该事件在编辑器启动完成后自动触发，无需用户打开任何文件或执行任何命令。

因此，只要该扩展被安装并启用，即使从不打开 Solidity 文件，IDE 每次启动完成或扩展进程重启时，都会自动调用 activate() 函数，恶意代码随即开始运行。

2.3 哈希混淆隐藏命令执行

在 out/extension.js 中，开发者并没有直接使用 child_process.exec，而是先对 Node.js 内置模块名和函数名计算 SHA-256 哈希，然后用两个固定哈希值去反查，得到 child_process 和 exec 两个字符串。因此，代码中的变量 hash 实际上就指向了 child_process.exec。

随后，代码将 hash（实为函数）与一个固定字符串做比较，由于函数对象永远不等于字符串，该比较结果始终为真，从而绕过检查并执行 attempt_update(child_process.exec)。attempt_update 函数利用传入的 exec 执行系统命令，开始安装持久化后门。

2.4 跨平台持久化

在 attempt_update 内部，程序先通过 os.platform() 判断操作系统，然后根据不同平台调用 exec 写入恶意文件，并设置对应的自启动项。一旦持久化完成，恶意载荷就不再依赖于 IDE 进程，即使卸载扩展也能继续运行。

• macOS：将载荷写入 ~/.solidity/，清除隔离属性，再创建 LaunchAgent，使其随用户登录启动。

• Linux：将载荷写入 ~/.solidity/，注册为 systemd 用户服务，并在异常退出后重启。

• Windows：将更新器写入 C:\Users\Public\solidity\，由其下载并执行 app.js；相关文件被隐藏，同时写入 HKCU Run 键，并尝试添加 Defender 排除项。

此后，Windows 从 C:\Users\Public\solidity\solidity-compiler.js 启动，macOS/Linux 则运行 ~/.solidity/ 下的原生文件。持久化机制保证载荷能够再次启动；而每次启动后连接到哪里，则由同一个以太坊合约决定。

2.5 利用以太坊合约动态更新 C2

Windows 与 macOS/Linux 读取同一份链上配置，但使用不同参数。

Windows 落地的 solidity-compiler.js 由 out/components/compiler.js 生成。脚本轮询多个公共 RPC，通过 eth_call 读取 param2()，再调用 curl.exe -k 下载并执行 app.js。参数 -k 会关闭 TLS 证书校验，脚本也不验证数字签名或固定哈希。用户再次登录时，HKCU Run 键会启动该脚本并重新查询下载地址。

macOS/Linux 使用 extension/bin/ 下按系统和 CPU 架构区分的 Go 可执行文件。样本保留的函数符号包括 antivm.Check、eth.ReadParam1WithFallback、hubclient.startShellLocked 和 runCommand。结合调用关系可以确认，载荷会进行运行环境检查，从合约读取 param1()，建立远程 Shell，并在断线后重连。

两类载荷硬编码了同一个以太坊主网合约：

0xf8a900db50b3331be6b768ba460bb59f3e40c344

逆向合约字节码后，可以识别出两项关键配置：param1()（0x02d91518）保存 macOS/Linux 的远程 Shell 地址，param2()（0x1f049b68）保存 Windows 二阶段载荷的下载地址。更新两项参数的函数选择器分别为 0xc832508f 和 0xf56f9b48，均受 owner 权限限制。调用 owner()（0x8da5cb5b）得到控制钱包 0xFd3fc58bcbd8ccc77b6000201438eDfc636E7cA7。

截至复核时，合约中的配置为：

感染主机只需通过公共 RPC 发起 eth_call：Windows 读取 param2() 下载 app.js，macOS/Linux 读取 param1() 连接远程 Shell。攻击者修改合约参数后，所有再次查询的载荷都会取得新地址，无需重新发布 VSIX。

把 C2 地址放到合约后，扩展包中只需保留合约地址和查询逻辑。公共 RPC 可以替换，单个节点失效不会切断配置读取；而每次参数更新也会留下链上记录。本文只对合约进行了只读查询，没有连接远程 Shell，也没有访问或下载二阶段载荷。链上仍保存这些地址，不代表对应服务器当前可达，也不能证明仍有活跃受害者。

2.6 链上 C2 更新记录

通过 Blockscout 查看该合约的交易历史，可以追踪参数的变化过程。我们筛选出控制钱包向合约发送的交易，然后根据函数选择器区分 param1 和 param2，并在交易输入数据的 UTF-8 部分直接看到写入的内容。

该合约于 2026 年 3 月 14 日 13:03 UTC 部署。20 分钟后，控制钱包发起交易（0x972f...）调用 0xc832508f，将 param1 设为 http://localhost:4912，随后又多次改为其他公网 IP。这说明在恶意扩展上架之前，攻击者就已经在测试这套链上控制机制。

该扩展于 5 月 1 日上架市场。两天后（5 月 3 日 16:55 UTC），控制钱包通过另一笔交易（0xadea...）将 param1 改为 107[.]189[.]27[.]46:4912。

5 月 16 日 12:08 UTC，同一钱包再通过交易（0x8e5d...）将 param2 改为  hxxp://107[.]189[.]27[.]46:3000/app.js。

两笔交易都发生在VSIX发布之后，说明攻击者无需经过扩展市场更新，就能更换远程Shell和二阶段下载地址。由于更新发生在链上，TRAE显示的扩展版本与更新时间不会随之变化。

2.7 下架扩展无法清除感染

TRAE 没有同步 Open VSX 的下架结果，导致已被上游删除的 VSIX 文件仍在继续分发。即使现在紧急下架，也只能防止新的安装，无法清除已经写入系统的恶意载荷。

因为扩展首次运行时，就已经在系统中创建了自启动项（macOS 的 LaunchAgent、Linux 的 systemd 服务、Windows 的注册表项），并且可能已经下载了第二阶段恶意代码。这些残留内容不会因为扩展被下架或用户卸载而自动删除，链上的 C2 配置也独立于扩展本身，依然有效。

图片
图片

因此，平台除了下架并停止提供 VSIX，还需通知已安装用户、提供检测和清理方案，并根据扩展 ID、文件哈希及落地 IOC 在客户端侧阻断。

2.8 感染排查与处置

如果曾安装过 juannegro.solidity，仅从 IDE 的扩展列表中卸载是不够的。建议先断开网络连接，并备份可疑文件用于后续取证，然后检查以下位置：

  • macOS：检查 ~/solidity/ 目录以及 ~/Library/LaunchAgents/com.solidity.langsupport.runner.plist 文件。

  • Linux：检查 ~/solidity/ 目录以及 ~/.config/systemd/user/solidity-langsupport-runner.service 文件。

  • Windows：检查 C:\Users\Public\solidity\ 目录，以及注册表项 HKCU\Software\Microsoft\Windows\CurrentVersion\Run 下是否有指向 solidity-compiler.js 的可疑启动项；同时检查 HKCU\Software\Microsoft\Windows\CurrentVersion\EVJ（若存在）。

另外，需检查主机是否有访问公共以太坊 RPC 节点以及以下 IP 和端口的网络连接记录：107[.]189[.]27[.]46:4912 和 107[.]189[.]27[.]46:3000。

该恶意扩展具备执行任意命令和建立远程 Shell 的能力。因此，即使删除了上述文件和注册表项，也不能认为系统已经安全。如果该设备曾存储过代码签名密钥、SSH 私钥、云服务凭证、加密钱包助记词或生产环境令牌，请按主机失陷流程处理：

  • 立即隔离该设备；

  • 从可信的安装介质重装操作系统或重建环境；

  • 在另一台安全设备上吊销所有旧会话和访问令牌，并更换所有可能被泄露的凭据。

2.9 威胁指标（IOC）

扩展与文件哈希

Extension: juannegro.solidity@0.0.189
VSIX SHA-256: ff943371750ecd2ce6caa50c12d673e82743bdbc9569552eebfa98ccb2f4ac69

darwin_amd64: 80d2672e2599732d3c0ae2a4cd0d1e3fe4d555a60273ce33feb99db3f34d250f
darwin_arm64: fae61f31f00988fdc5cc9e7272b51e08af2e245d81003237875415930fd27358
linux_amd64: 9b73e7cd4e1425e770392549d8df46c706139ef476f4f7b9ac405165dc8d9696
linux_arm64: b601776817363b96295119f7221338a122d5247a35a77a64b04f286e1bbcc565

链上与网络指标

Contract: 0xf8a900db50b3331be6b768ba460bb59f3e40c344
Owner: 0xFd3fc58bcbd8ccc77b6000201438eDfc636E7cA7

107[.]189[.]27[.]46:4912
hxxp://107[.]189[.]27[.]46:3000/app.js
91[.]108[.]240[.]156:4912
hxxp://91[.]108[.]240[.]156:3000/app.js
107[.]189[.]16[.]215:4912

由于合约参数会持续更新，检测时不能仅依赖当前 IP，还需要覆盖合约地址、函数选择器、恶意文件释放路径、自启动项名称以及样本哈希等特征。

三、总结

juannegro.solidity 的真正危险不仅仅是 TRAE 没有同步下架信息。它利用扩展市场作为首次投放渠道，在 Windows、macOS 和 Linux 上都建立了持久化后门，并通过以太坊合约获取动态可变的 C2 配置。5 月 3 日和 5 月 16 日的链上交易证明，攻击者在 VSIX 发布后仍然持续更新远程 Shell 和第二阶段载荷的地址。

扩展市场平台不能只同步上架信息，还必须同步风险判定和下架状态，并及时通知已安装的用户。否则，Open VSX 已经完成的处置在 TRAE 上形同虚设，而已经植入系统的后门也不会因市场下架而消失，仍然可以绕过市场继续运行。

关于 MistEye

MistEye 是由 SlowMist 自主研发的 Web3 威胁情报与动态安全监控平台，通过 API 提供开源包生态的恶意活动检测与供应链风险预警能力。

本次行动涉及的全部恶意包及 IOC 已接入 MistEye 威胁检测引擎，开发者可通过 API 对项目依赖进行自动化检测，快速判定是否命中已知恶意包并获取处置建议。

📖 API 文档：https://app.misteye.io/api-docs

🛠️ MistEye-DepScan：https://github.com/slowmist/MistEye-DepScan  轻量级 CLI 工具，一行命令扫描项目依赖与全局安装包中的已知恶意包，支持 npm / PyPI / Cargo / Go / RubyGems 生态

🛠️ MistEye-Skills：https://github.com/slowmist/misteye-skills  AI 编码助手安全技能包，在依赖安装与 URL 访问前自动触发 MistEye 安全检测