This article is a part of our Vulnerability Database (back to index)
Cross-site Scripting occurrences in Osticket
Cross-site Scripting (XSS) - Reflected in GitHub repository osticket/osticket prior to 1.16.4. (2022-12-02, CVE-2022-4271)
A stored cross-site scripting (XSS) vulnerability in the component audit/class.audit.php of osTicket-plugins - Storage-FS before commit a7842d494889fd5533d13deb3c6a7789768795ae allows attackers to execute arbitrary web scripts or HTML via a crafted SVG file. (2022-07-13, CVE-2022-32074)
Cross Site Scripting (XSS) vulnerability in Enhancesoft osTicket before v1.12.6 via the queue-name parameter in include/class.queue.php. (2021-06-28, CVE-2020-22609)
Cross Site Scripting vulnerability in Enhancesoft osTicket before v1.12.6 via the queue-name parameter to include/ajax.search.php. (2021-06-28, CVE-2020-22608)
osTicket before 1.14.3 allows XSS via a crafted filename to DraftAjaxAPI::_uploadInlineImage() in include/ajax.draft.php. (2020-08-30, CVE-2020-24917)
osTicket before 1.14.3 allows XSS because include/staff/banrule.inc.php has an unvalidated echo $info['notes'] call. (2020-08-26, CVE-2020-16193)
scp/categories.php in osTicket 1.14.2 allows XSS via a Knowledgebase Category Name or Category Description. The attacker must be an Agent. (2020-06-10, CVE-2020-14012)
include/class.sla.php in osTicket before 1.14.2 allows XSS via the SLA Name. (2020-05-04, CVE-2020-12629)
An issue was discovered in osTicket before 1.10.7 and 1.12.x before 1.12.1. Stored XSS exists in setup/install.php. It was observed that no input sanitization was provided in the firstname and lastname fields of the application. The insertion of malicious queries in those fields leads to the execution of those queries. This can further lead to cookie stealing or other malicious actions. (2019-08-07, CVE-2019-14750)
An issue was discovered in osTicket before 1.10.7 and 1.12.x before 1.12.1. The Ticket creation form allows users to upload files along with queries. It was found that the file-upload functionality has fewer (or no) mitigations implemented for file content checks; also, the output is not handled properly, causing persistent XSS that leads to cookie stealing or malicious actions. For example, a non-agent user can upload a .html file, and Content-Disposition will be set to inline instead of attachment. (2019-08-07, CVE-2019-14748)
Unauthenticated Stored XSS in osTicket 1.10.1 allows a remote attacker to gain admin privileges by injecting arbitrary web script or HTML via arbitrary file extension while creating a support ticket. (2019-07-09, CVE-2019-13397)
In osTicket before 1.12, XSS exists via /upload/file.php, /upload/scp/users.php?do=import-users, and /upload/scp/ajax.php/users/import if an agent manager user uploads a crafted .csv file to the User Importer, because file contents can appear in an error message. The XSS can lead to local file inclusion. (2019-04-25, CVE-2019-11537)
Cross-site scripting (XSS) vulnerability in /ajax.php/form/help-topic in Enhancesoft osTicket before 1.10.2 allows remote attackers to inject arbitrary web script or HTML via the "message" parameter. (2018-03-27, CVE-2018-7192)
Cross-site scripting (XSS) vulnerability in /scp/directory.php in Enhancesoft osTicket before 1.10.2 allows remote attackers to inject arbitrary web script or HTML via the "order" parameter. (2018-03-27, CVE-2018-7193)
Cross-site scripting (XSS) vulnerability in /scp/index.php in Enhancesoft osTicket before 1.10.2 allows remote attackers to inject arbitrary web script or HTML via the "sort" parameter. (2018-03-27, CVE-2018-7196)
Why Cross-site Scripting can be dangerous
Cross site scripting is an attack where a web page executes code that is injected by an adversary. It usually appears, when users input is presented. This attack can be used to impersonate a user, take over control of the session, or even steal API keys.
The attack can be executed e.g. when you application injects the request parameter directly into the HTML code of the page returned to the user:
https://server.com/confirmation?message=Transaction+Complete
what results in:
<span>Confirmation: Transaction Complete</span>
In that case the message can be modified to become a valid Javascript code, e.g.:
https://server.com/confirmation?message=<script>dangerous javascript code here</script>
and it will be executed locally by the user's browser with full access to the user's personal application/browser data:
<span>Confirmation: <script>dangerous javascript code here</script></span>