文章总结： Mockoon管理API存在免凭据后门漏洞（CVE-2026-59148等），攻击者可劫持mock状态、窃取凭据。实验展示六步攻击流程，9.7.0版本已修复。建议升级后轮换泄露凭据、配置访问令牌、限制绑定地址，并建立开发工具资产清单。 综合评分： 85 文章分类： 漏洞分析,安全工具,应急响应

Mockoon：管理 API 为什么成了免凭据后门

原创

云梦DC 云梦DC

云梦安全

2026年10月2日 09:00 河南

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

2026 年 9 月 11 日，Mockoon 披露 GHSA-rqx4-3f6q-3x2v（CVE-2026-59148，高危）：@mockoon/commons-server 与 @mockoon/cli 9.7.0 之前版本的管理 API 没有鉴权，并对任意来源放开 CORS，可被用来劫持 mock 状态、窃取凭据。同一天还有一个同思路的问题 GHSA-8wqc-v2q8-vff2（CVE-2026-59149），模板 filePath 的前缀校验可被绕过。

Mockoon 是接口模拟工具：后端还没上线时，前端和 CI 就对着它调。正因为它是“临时的、测试用的”，这类端口最容易被顺手开到 0.0.0.0，也最容易被资产台账漏掉。下面的实验说明，一旦能连上这个端口，得到的比“能改几个 mock 响应”要多得多。

实验：一次正常调用，把凭据留在了日志里

环境里跑的是 @mockoon/cli 9.6.1，业务路由 /payments/status 监听 127.0.0.1:4001。基线先确认业务正常：GET 返回 200 和一段账务 mock 数据。接着带 Bearer lab-session-7f21ac9e 请求一次，模拟前端或 CI 的正常调用。

然后是不带任何凭据的六步。

第一步，带 Origin: https://attacker.example 访问 GET /mockoon-admin，返回 200，响应头里 Access-Control-Allow-Origin: *，并放开了 GET、POST、PUT、PATCH、DELETE、HEAD、OPTIONS 全部方法。通配 CORS 意味着任何一个浏览器页面都能读到这个响应——不需要用户点什么，打开页面就行。

第二步，GET /mockoon-admin/env-vars/MOCKOON_API_KEY 直接返回 {"key":"MOCKOON_API_KEY","value":"sk-live-lab-9f3c7a21d4e8"}。这些环境变量本来是配置给模拟服务用的，很多团队会把“以后要用的真密钥”顺手放进去。

第三步，GET /mockoon-admin/logs 返回最近两次请求的完整记录，其中就包括刚刚那条调用原样携带的 Authorization: Bearer lab-session-7f21ac9e。这一步的杀伤力最大：mock 端口的请求日志会把开发者和 CI 的真实凭据抄下来，而这条链路同样不需要任何凭据。

第四步，POST /mockoon-admin/env-vars 可以写任意进程环境变量，实验里把 AWS_SECRET_ACCESS_KEY 改成了 AKIA-LAB-POISONED。第五步，PUT /mockoon-admin/environment 在运行时改写了业务响应体，/payments/status 的返回里多出 "payTo":"ACME-ATTACKER-4242"。第六步，PURGE /mockoon-admin/logs 清空审计日志——破坏性方法同样不校验来源。

结论很直接：能连上 mock 端口的任何来源，都等价于持有该实例的管理员权限。

9.7.0 修了什么

升级到 9.7.0 后，同样六步全部返回 401 Unauthorized，Access-Control-Allow-Origin 也不再下发；业务路由 /payments/status 仍然 200，正常功能没有受影响。

升级之后更该做的事

这类漏洞的修复相对干净，但善后比升级本身重要，因为它牵涉“已经泄露了什么”。

如果 mock 端口曾经暴露在非可信网络里，请把“所有出现在 mock 请求里的凭据”视为已泄露：请求日志里出现过的 Authorization、请求头里的 API Key，以及被塞进 mock 环境变量的真密钥，全部要轮换。同时审计一遍现有 mock 配置里的环境变量，把不是模拟数据的真凭据挪出去——mock 的 env 和生产的 env 混用，是这类事件里最常见的放大器。

配置侧的动作有三条：给管理 API 设置访问令牌并确认无凭据访问返回 401；把 mock 服务绑定到 127.0.0.1 或容器内网，不要暴露到办公网和公网；把常见 mock 端口纳入资产台账并定期探测，别让“临时开的测试端口”活过一个迭代。

检测与复测

日志侧可以关注 /mockoon-admin 路径的访问记录，尤其是来自非预期网段、带外部 Origin 的请求，以及紧跟其后的 env-vars、logs、environment 调用——这个组合不像是正常运维操作。

复测固定三项：无凭据访问管理 API 应 401；带令牌访问管理 API 应正常；业务 mock 路由的功能与响应结构回归正常。另外建议做一次“凭据轮换是否完成”的确认，这一步比升级版本号更能反映真实风险。

为什么 mock 端口特别容易被漏掉

安全台账通常按“域名 + 端口 + 责任人”登记，而 mock 服务的特征是：由前端或测试同学随手启动、经常以容器端口直接映射到宿主机、没有域名、也没有独立的负责人。探测资产时，它不会出现在任何接口文档里；扫漏洞时，它返回的都是正常业务数据，看不出异常。等到有人把它开到公网，风险才以“测试端口暴露”的形式出现。

一个务实的做法是把这类服务按“开发工具”单独建一份清单：本机开发环境、共享测试环境、CI 流水线里各有哪些、分别绑定了什么地址。这份清单不需要很正式，只要能在排查时回答一个问题——现在还有哪些 mock 实例在监听，它们各自能读到哪些环境变量。

一句话总结

“测试用的模拟服务”和“生产服务”在权限上没有区别——只要它持有密钥、能被访问、又没人管它的身份校验，它就是一条后门。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：云梦安全 云梦DC 云梦DC《Mockoon：管理 API 为什么成了免凭据后门》