elecV2P：RCE、任意文件读取、XSS、SSRF 同时出现，重点已经不是漏洞名字了｜CVE-2026-3955 等

原创

ZAST.AI
ZAST.AI

ZAST.AI

2026年6月24日 18:14
福建

在小说阅读器读本章

去阅读

elecV2P 这组问题很容易被概括成一句空话：一个项目里有很多漏洞。

但如果只停在这个层面，就会错过真正值得看的地方。ZAST.AI 这次验证下来的 7 个问题虽然分布在 RCE、任意文件读取、XSS 和 SSRF 四种不同类别里，但它们暴露出来的其实是同一个更底层的失误：请求数据被认为是合法数据并拼接到代码中执行。

具体来说，就是请求数据有的时候被直接当成了可执行代码，有的时候被当成了文件路径，有的时候被当成了返回给浏览器的 HTML，有的时候又直接被当成了服务端要访问的目标。

一、最危险的一组是三条代码执行路径

CVE-2026-3955 对应的是 /jsfile。

公开报告里这条路径非常直白：

app.post('/jsfile', (req, res) => {
  ...
  case 'totest':
    runJSFile(jscontent, {
      type: 'rawcode',
      filename: jsname.replace(/\\.(js|efh)$/, '-test.$1'),
      from: 'test',
      ...
    })

这里的问题不在于测试脚本功能本身，而是 jscontent 这种用户输入在 type=totest 时会直接进入 runJSFile()。公开报告还进一步说明，后续解析里存在 new Function(\"return \" + str) 这样的不安全执行方式，因此攻击者可以通过输入：

process.mainModule.require('child_process').exec('ping -c 4 $domain')

代码执行，甚至进一步走到系统命令。DNS 回连已经把这条链路打实了。

另外两条 RCE 也和这个模式很像：

• CVE-2026-5011：/webhook接口接收rawcode参数内容 ，然后把它传递到runJSFile方法中，导致任意代码执行；/rpc接口 接收 pm2run参数内容，并直接拼接到 exec('pm2 start ' + params[0] + ' --attach --no-autorestart')实现命令执行
• CVE-2026-5012：/rpc 里的 pm2run 把 params[0] 直接拼进 exec('pm2 start ' + params[0] + ' --attach --no-autorestart')

也就是说，这三条路径虽然入口不同，但本质上都把请求数据推到了执行边界上。

二、两条任意文件读取说明文件边界也一样松

CVE-2026-5013 和 CVE-2026-5014 对应的是两组路径穿越问题。

第一条是 /store/:key：

app.get(\"/store/:key\", (req, res) => {
  res.send(sString(store.get(req.params.key, 'raw')));
})
...
let keypath = path.join(fpath.store, key)
let value = fs.readFileSync(keypath, 'utf8')

公开报告指出，这里没有做有效路径约束，URL 编码后的 ../ 可以跳出原本的 store 目录，最后直接读到任意文件，并将被读取的文件内容返回到响应体。

第二条是 /log/* 和 /logs/*：

const filename = req.params[0].replace(/\\/$/, '')
const logcont = LOGFILE.get(filename)
...
let logfpath = path.join(CONFIG_LOG.logspath, filename)
return fs.createReadStream(logfpath)

这组问题和前一条很像，区别只是目标目录从 store 目录换成了日志目录。文件名一旦能控制到 path.join(...)，边界就失守了。

三、浏览器侧和网络侧也出现了同样的信任问题

CVE-2026-5015 是 /logs 上的 reflected XSS。

公开报告里最关键的一行是：

res.write(`<li class=\"logsnav_item${log===filename ? ' logsnav_item--curt' : ''}\">${log}</li>`)

也就是说，攻击者可控的值会直接进入 HTML 输出，而且没有做转义。到了这里，问题就已经不是“日志页面会不会显示一些奇怪字符”，而是浏览器端脚本执行边界直接被打开了。

CVE-2026-5016 则是 /mock 上的 SSRF：

app.put('/mock', (req, res) => {
  const request = req.body.request
  switch (req.body.type) {
    case 'req':
      eAxios(request).then(response => {

公开报告的总结很清楚：当 type的值为req时，服务端就会把请求体里的 request 对象传入 eAxios()方法，既没有认证，也没有 URL 约束。DNS 回连已经证明SSRF漏洞存在。

四、为什么这组问题不能只按漏洞类型分开看

如果按名字拆开，它们当然是：

• 3 个 RCE
• 2 个任意文件读取
• 1 个 XSS
• 1 个 SSRF

但从系统设计角度看，这些问题更像在重复同一种错误：

• 请求数据被当成代码
• 请求数据被当成命令参数
• 请求数据被当成文件路径
• 请求数据被当成 HTML 内容
• 请求数据被当成服务端请求定义

这也是为什么 elecV2P 这组问题比单独某一个 CVE 更值得看。因为它说明这里的问题已经不是“某个接口写漏了校验”，而是多个辅助能力、工具型路由和系统接口都没有守住各自的边界。

五、修复重点不该只是按 issue 打补丁

这类项目真正需要回看的，不是某一个函数，而是一整套边界：

• 哪些路由允许请求数据触发脚本或命令执行
• 哪些路由允许请求数据指定文件位置
• 哪些页面把外部输入直接拼进 HTML
• 哪些接口允许外部输入定义服务端出站请求

如果修法只是“把这次公开的 7 个点补掉”，那很可能只是把明面上的洞堵住，却没有把系统对请求数据的信任范围真正收回来。

六、结语

CVE-2026-3955、CVE-2026-5011、CVE-2026-5012、CVE-2026-5013、CVE-2026-5014、CVE-2026-5015、CVE-2026-5016 放在一起看，最重要的并不是“漏洞种类很多”，而是这个项目在执行、文件、浏览器和网络四个方向上，都让请求数据越过了不该越过的边界。

这也是为什么验证比猜测更重要。ZAST.AI 这次不是只识别出 exec(...)、path.join(...)、res.write(...)、eAxios(...) 这些可能存在漏洞风险的代码，而是把真正能走到代码执行、任意文件读取、XSS 和 SSRF 的路径都验证了下来。

完整报告：

https://github.com/elecV2/elecV2P/issues/194

https://github.com/elecV2/elecV2P/issues/195

https://github.com/elecV2/elecV2P/issues/196

https://github.com/elecV2/elecV2P/issues/199

https://github.com/elecV2/elecV2P/issues/200

https://github.com/elecV2/elecV2P/issues/201

https://github.com/elecV2/elecV2P/issues/202