CVE-2026-14871 - BOLA / IDOR in osTicket ajax.tickets.php

Broken Object Level Authorization (BOLA): Insecure Direct Object Reference (IDOR)
include/ajax.tickets.php → viewField() function
Reported by @JF0x0r · March 27, 2026 Status: PATCHED - Fix released in osTicket v1.17.8 / v1.18.4

At a Glance

Whoami

I'm Juan Felipe Oz (@JF0x0r), a security researcher passionate about open source security. I don't do this for bounties i do it because i believe the tools people rely on should be safe. When I find something, I report it responsibly, document it properly, and share it publicly once it's fixed.

What I Found

While doing a manual code review of osTicket's AJAX subsystem, I noticed something off in ajax.tickets.php. The viewField() function handles requests to view ticket field data - and it does retrieve the ticket object and validates the field exists. But it never checks whether the requesting agent actually has permission to access that ticket.

No checkStaffPerm(). No department validation. Nothing.

This means any authenticated agent, even one strictly limited to a single department can read ticket fields from any other department in the system, just by knowing or guessing the ticket_id and field_id. Those are sequential integers. Easy to enumerate.

What makes this particularly clear-cut is the comparison with editField(), the sister function right above it in the same file. editField() correctly calls $ticket->checkStaffPerm($thisstaff, Ticket::PERM_EDIT) and returns HTTP 403 on violation. The fix was already implemented for writes — it was simply never applied to reads.

Proof of Concept: Live Demo

I recorded a full end-to-end demonstration of the exploit in a controlled lab environment:

The video walks through:

• Lab setup with two isolated departments (Dept-A and Dept-B)
• Agent agent_a authenticated with access restricted to Dept-A only
• Crafting the unauthorized request targeting a Dept-B confidential ticket
• The server returning HTTP 200 with the restricted ticket field data exposed
• Replay after the patch showing HTTP 403 — Permission denied

The exploit.py script in this repository automates the full chain (authentication → enumeration → unauthorized field access) and was used during the assessment to confirm the issue scales beyond manual testing.

Impact

• Sensitive data disclosure - any agent can read confidential ticket fields across all departments
• Horizontal privilege escalation - departmental boundaries are completely bypassed
• Mass enumeration - sequential ticket_id / field_id integers make bulk scraping trivial
• Multi-tenant confidentiality breach - defeats the core design principle of osTicket's department isolation model

The Fix

A single line insertion in viewField(), immediately after the ticket object is retrieved - mirroring exactly what editField() already does correctly. Full technical details, diff, and CVSS breakdown are in the attached report.

📄 BOLA_IDOR_osTicket_Report_v2.pdf

✅ Official Patch (Confirmed by osTicket Team)

osTicket confirmed the report and implemented the mitigation by adding $ticket->checkStaffPerm($thisstaff) before resolving/rendering the requested field - mirroring the check already present in editField(). Staff must now have access to the parent ticket before viewing field data.

osTicket recommends a short upgrade buffer before sharing full exploit steps publicly. This repo follows that guidance - see Disclosure Timeline below.

Disclosure Timeline

Files in This Repo

.
├── 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

Responsible Disclosure

I reported this privately to the osTicket security team before publishing anything. This repository was made public only after the responsible disclosure window, and now that an official patch has shipped, the full write-up is available. If you are an osTicket maintainer and have questions, feel free to reach out directly via GitHub.

Found by @JF0x0r · Open source security matters.