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() Funktion
Gemeldet von @JF0x0r · 27. März 2026
Status: GEPATCHT - Fix veröffentlicht in osTicket v1.17.8 / v1.18.4

Auf einen Blick

Wer ich bin

Ich bin Juan Felipe Oz (@JF0x0r), ein Sicherheitsforscher, der sich leidenschaftlich für Open-Source-Sicherheit einsetzt. Ich mache das nicht für Bountys, sondern weil ich glaube, dass die Werkzeuge, auf die Menschen angewiesen sind, sicher sein sollten. Wenn ich etwas finde, melde ich es verantwortungsvoll, dokumentiere es ordnungsgemäß und teile es öffentlich, sobald es behoben ist.

Was ich gefunden habe

Bei einer manuellen Code-Überprüfung des AJAX-Subsystems von osTicket ist mir etwas in ajax.tickets.php aufgefallen. Die Funktion viewField() bearbeitet Anfragen zur Anzeige von Ticketfelddaten – sie ruft das Ticketobjekt ab und prüft, ob das Feld existiert. Aber sie prüft nie, ob der anfragende Agent tatsächlich die Berechtigung hat, auf dieses Ticket zuzugreifen.

Kein checkStaffPerm(). Keine Abteilungsvalidierung. Nichts.

Das bedeutet, dass jeder authentifizierte Agent, selbst wenn er streng auf eine einzige Abteilung beschränkt ist, Ticketfelder aus jeder anderen Abteilung im System lesen kann – nur durch Kenntnis oder Erraten der ticket_id und field_id. Dies sind sequentielle Ganzzahlen. Leicht zu enumerieren.

Was dies besonders eindeutig macht, ist der Vergleich mit editField(), der Schwesterfunktion direkt darüber in derselben Datei. editField() ruft korrekt $ticket->checkStaffPerm($thisstaff, Ticket::PERM_EDIT) auf und gibt bei Verstoß HTTP 403 zurück. Der Fix war bereits für Schreibvorgänge implementiert – er wurde nur nie auf Lesevorgänge angewendet.

Proof of Concept: Live-Demo

Ich habe eine vollständige End-to-End-Demonstration des Exploits in einer kontrollierten Laborumgebung aufgezeichnet:

Das Video zeigt:

• Laboraufbau mit zwei isolierten Abteilungen (Dept-A und Dept-B)
• Agent agent_a authentifiziert mit Zugriff nur auf Dept-A
• Erstellen der unbefugten Anfrage, die ein vertrauliches Ticket von Dept-B anvisiert
• Der Server antwortet mit HTTP 200 und gibt die eingeschränkten Ticketfelddaten preis
• Wiederholung nach dem Patch zeigt HTTP 403 – Zugriff verweigert

Das Skript exploit.py in diesem Repository automatisiert die gesamte Kette (Authentifizierung → Enumeration → unbefugter Feldzugriff) und wurde während der Bewertung verwendet, um zu bestätigen, dass das Problem über manuelle Tests hinausgeht.

Auswirkungen

• Offenlegung sensibler Daten – jeder Agent kann vertrauliche Ticketfelder in allen Abteilungen lesen
• Horizontale Privilegieneskalation – Abteilungsgrenzen werden vollständig umgangen
• Massen-Enumeration – sequentielle ticket_id- / field_id-Ganzzahlen machen Massen-Scraping trivial
• Vertraulichkeitsverletzung bei mehreren Mandanten – das grundlegende Designprinzip der Abteilungsisolierung von osTicket wird ausgehebelt

Der Fix

Eine einzelne Zeileneinfügung in viewField(), unmittelbar nachdem das Ticketobjekt abgerufen wurde – genau das, was editField() bereits korrekt tut. Vollständige technische Details, Diff und CVSS-Aufschlüsselung finden Sie im beigefügten Bericht.

📄 BOLA_IDOR_osTicket_Report_v2.pdf

✅ Offizieller Patch (bestätigt durch das osTicket-Team)

osTicket bestätigte den Bericht und implementierte die Abhilfe, indem $ticket->checkStaffPerm($thisstaff) vor dem Auflösen/Rendern des angeforderten Feldes hinzugefügt wurde – dies spiegelt die bereits in editField() vorhandene Prüfung wider. Mitarbeiter müssen nun Zugriff auf das übergeordnete Ticket haben, bevor sie Felddaten anzeigen können.

osTicket empfiehlt eine kurze Upgrade-Frist, bevor vollständige Exploit-Schritte öffentlich geteilt werden. Dieses Repository folgt dieser Richtlinie – siehe Offenlegungszeitplan unten.

Offenlegungszeitplan

Dateien in diesem Repository

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

Verantwortungsvolle Offenlegung

Ich habe dies privat an das osTicket-Sicherheitsteam gemeldet, bevor ich etwas veröffentlicht habe. Dieses Repository wurde erst nach Ablauf der verantwortungsvollen Offenlegungsfrist und nachdem ein offizieller Patch ausgeliefert wurde, öffentlich gemacht. Der vollständige Bericht ist nun verfügbar. Wenn Sie ein osTicket-Maintainer sind und Fragen haben, können Sie mich gerne direkt über GitHub kontaktieren.

Gefunden von @JF0x0r · Open-Source-Sicherheit ist wichtig.