2026-04-16 04:45:02 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： 本文披露了Zammad客服系统中未认证API接口(CVE-2026-34723)导致的信息泄露漏洞。研究员通过子域名枚举发现’newzammad’测试环境，两个未认证接口(/api/v1/getting_started和/api/v1/signshow)泄露了内部邮箱、部门结构、SSO配置等敏感信息。这些信息组合后可构建精准钓鱼攻击链，最终被厂商评定为高危漏洞(CVSS8.7)。建议用户立即升级至6.5.4/7.0.1版本并检查接口认证。 综合评分： 85 文章分类： 漏洞分析,渗透测试,WEB安全,安全意识,威胁情报

cover_image

我使用了两个Endpoints，结果被判定为 CVE

haidragon haidragon

安全狗的自我修养

2026年4月14日 12:37 湖南

在小说阅读器读本章

去阅读

官网：http://securitytech.cc

如何一个未认证的 Zammad API 泄露组织结构、认证后端以及钓鱼攻击路径 — CVE-2026–34723

curl → HTTP 200 → 钓鱼 → 横向移动（pivot）。这就是“仅仅信息泄露”在现实中的真正影响。

没有利用链。没有 0day。没有高级工具。

只有一个 curl 命令、一个我差点忽略的子域名，以及两个“忘记做认证”的 API 接口。

这就是 CVE-2026–34723 的由来。

目标

我当时正在做一个负责任披露项目 —— 梳理攻击面：主站、客户门户、Web 邮件、状态页面。这些都是常规流程。

同时我也在做子域名枚举，因为漏洞赏金第一条原则是：

👉 项目列出来的资产，往往不是最有意思的漏洞所在

很快，一个子域名引起了注意：

1. newzammad.[redacted].net

主机名里带“new”，对安全研究员来说就是诱饵：

新部署
测试环境
迁移系统
新配置

👉 通常意味着：没有像生产环境一样被认真审计

经验告诉我：必须深挖。

Zammad 是什么

Zammad 是一个流行的开源工单/客服系统。

这个实例给了我一个未认证的登录页面（很正常）。

但关键在于：

👉 Zammad 是高度依赖 API 的系统

它的 JavaScript bundle，本质上就是一张“接口地图”。

于是我开始：

👉 用 curl 直接打接口，看看哪些返回 401，哪些没有。

接口分析

/api/v1/getting_started

1. curl&nbsp;-s https://newzammad.[redacted].net/api/v1/getting_started&nbsp;|&nbsp;python3&nbsp;-m json.tool

👉 无需登录 👉 无 Cookie 👉 直接返回数据

返回内容：

5 个内部邮箱（support@、billing@、测试账号）
10 个部门/分组名称：
Support 1st line
2nd line
3rd line
HR
Legal
Finance
VIP
Development-testing
每个部门的 SLA 配置（响应时间、升级规则）
开发者备注（例如：测试联系表单集成，从 cosmos2 创建工单）
邮件通道配置
系统历史记录（最早可追溯到 2007 年）

👉 这意味着：

❗ 这不是测试环境，而是一个迁移过来的真实生产系统 ❗ 并且带着多年配置“历史包袱”

/api/v1/signshow

第二个接口更加敏感：

使用 GitLab OAuth 作为 SSO
WebSocket 服务暴露在 6042 端口
同时启用 API Token + 密码认证（攻击面翻倍）
会话有效期 28 天（cookie 被盗可用一个月）

为什么“只是信息泄露”是错误判断

这一段是核心。

“信息泄露”经常被忽视。

研究员报告：

泄露邮箱
内部服务名称

👉 往往被标记为“信息性问题”然后关闭

👉 错误在于：

❌ 把每个信息点孤立来看 ✅ 而不是组合分析

把信息组合起来

我掌握的信息：

知道 billing@[redacted] 属于 Finance 部门，并有 SLA
知道使用 GitLab SSO → 攻破 GitLab = 直接进入系统
知道 API token + 密码双认证 → 攻击路径更多
知道 session 28 天 → 钓鱼成功后长期有效
知道组织结构 → 可以写“真实可信”的钓鱼邮件

👉 这意味着：

❗ 不是“小问题” ❗ 而是一个完整的“钓鱼攻击工具包”

攻击链：

1. 未认证&nbsp;API&nbsp;→信息收集→精准钓鱼→获取GitLab→进入Zammad→获取客户数据

👉 攻击者一旦拿到开发者 GitLab 凭据：

✔ 可以直接进入客服系统 ✔ 获取客户数据、工单、历史记录

漏洞评分

最初我给：

👉 CVSS 5.5（中危）

厂商后来改为：

👉 CVSS 8.7（高危）

👉 厂商是对的

披露时间线

| 日期 | 事件 | | — | — | | 2026-03-20 | 向目标组织报告（PGP 加密） | | | 安全团队确认并上报厂商 | | 2026-04-08 | 发布补丁 6.5.4 / 7.0.1 | | | GitHub 安全公告发布 | | 2026-04-13 | 作者署名恢复 | | Today | CVE 发布并进入漏洞数据库 |

关于署名

迁移公告到 GitHub 时：

👉 作者署名丢失了（不是故意的）

后来通过沟通恢复。

👉 经验：

如果你是研究员，署名丢了，一定要跟进

关键结论

1️⃣ 一定要做子域名枚举

主站是安全的漏洞在子域名

👉 “new” 子域 = 高风险

2️⃣ 未认证接口扫描被低估

没有利用链没有 RCE 只是没做认证

👉 但影响巨大

3️⃣ 上下文决定漏洞等级

| 单独看 | 组合看 | | — | — | | 部门名称 | 钓鱼模板 | | 邮箱 | 攻击目标 | | SSO | 横向入口 | | session | 持久控制 |

👉 单个信息没用 👉 组合就是攻击链

4️⃣ 厂商沟通很重要

好的安全团队会：

上报问题
推动修复
保证署名

影响版本 & 修复

漏洞影响：

👉 6.5.4 / 7.0.1 之前版本

修复方式：

👉 限制接口必须认证：

/api/v1/getting_started
/api/v1/signshow

👉 如果你在用 Zammad：

✔ 立即升级 ✔ 检查接口是否需要认证

参考

GitHub 安全公告
CVE-2026–34723
SentinelOne 数据库
官方网站
公众号:安全狗的自我修养
vx:2207344074
http://gitee.com/haidragon
http://github.com/haidragon
bilibili:haidragonx

#

免责声明：

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

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

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

本文转载自：安全狗的自我修养 haidragon haidragon《我使用了两个Endpoints，结果被判定为 CVE》