CVE-2026-14871 - osTicket ajax.tickets.php 中的 BOLA / IDOR 漏洞

对象级授权失效 (BOLA)：不安全的直接对象引用 (IDOR)
include/ajax.tickets.php → viewField() 函数
由 @JF0x0r 报告 · 2026年3月27日 状态：已修复 - 修复已在 osTicket v1.17.8 / v1.18.4 中发布

一览

关于我

我是 Juan Felipe Oz（@JF0x0r），一名热衷于开源安全的安全研究员。我这样做不是为了赏金，而是因为我坚信人们所依赖的工具应该是安全的。当我发现问题时，我会负责任地报告、妥善记录，并在修复后公之于众。

我发现了什么

在对 osTicket 的 AJAX 子系统进行手动代码审查时，我注意到 ajax.tickets.php 中有些不对劲。viewField() 函数处理查看工单字段数据的请求——它确实会检索工单对象并验证字段是否存在。但它从不检查发出请求的客服人员是否真的有权限访问该工单。

没有 checkStaffPerm()。没有部门验证。什么都没有。

这意味着任何已认证的客服人员，即使是严格限制在单个部门的客服人员，也可以读取系统中任何其他部门的工单字段，只需知道或猜测 ticket_id 和 field_id 即可。这些是连续的整数，很容易枚举。

更让这个问题一目了然的是与 editField() 的对比——它是同一文件中紧挨在上方的姊妹函数。editField() 正确调用了 $ticket->checkStaffPerm($thisstaff, Ticket::PERM_EDIT)，并在违规时返回 HTTP 403。写入操作的修复早已实现——只是从未应用到读取操作上。

概念验证：实况演示

我在受控的实验室环境中录制了一段完整的端到端漏洞利用演示：

视频演示了以下过程：

• 搭建包含两个相互隔离部门的实验室环境（Dept-A 和 Dept-B）
• 客服人员 agent_a 已完成认证，访问权限仅限于 Dept-A
• 构造针对 Dept-B 机密工单的未授权请求
• 服务器返回 HTTP 200，受限工单字段数据遭到泄露
• 修补后重放，显示 HTTP 403 — 权限被拒绝

本仓库中的 exploit.py 脚本自动化了整个攻击链（认证 → 枚举 → 未授权字段访问），在评估期间用于确认该问题的影响范围远超手动测试。

影响

• 敏感数据泄露 - 任何客服人员都可以跨所有部门读取机密工单字段
• 水平权限提升 - 部门边界被完全绕过
• 批量枚举 - 连续的 ticket_id / field_id 整数使批量抓取变得轻而易举
• 多租户机密性破坏 - 彻底违背了 osTicket 部门隔离模型的核心设计原则

修复方案

在 viewField() 中插入一行代码，紧接在检索到工单对象之后——与 editField() 已经正确执行的操作完全一致。完整的技术细节、diff 和 CVSS 分解见随附的报告。

📄 BOLA_IDOR_osTicket_Report_v2.pdf

✅ 官方补丁（osTicket 团队已确认）

osTicket 确认了该报告，并通过在解析/渲染所请求的字段之前添加 $ticket->checkStaffPerm($thisstaff) 实施了缓解措施——与 editField() 中已有的检查保持一致。现在，员工必须先拥有对父工单的访问权限，才能查看字段数据。

osTicket 建议在公开分享完整漏洞利用步骤之前留出短暂的升级缓冲期。本仓库遵循该建议——请参阅下方的披露时间线。

披露时间线

本仓库中的文件

.
├── README.md                        # This file
├── BOLA_IDOR_osTicket_Report_v2.pdf # Full technical disclosure report
├── exploit.py                       # PoC automation script
└── PoC_osTicket.mov                 # Local copy of the demo video

负责任披露

我在发布任何内容之前，已私下向 osTicket 安全团队报告了此问题。本仓库仅在负责任披露期结束后才公开，现在官方补丁已发布，完整的技术报告可供查阅。如果您是 osTicket 维护者并有疑问，欢迎直接通过 GitHub 联系。

由 @JF0x0r 发现 · 开源安全至关重要。