Share
## https://sploitus.com/exploit?id=8B0ABDA6-D053-5B34-9C21-0816802F9B88
# CVE-2026-36214 - Stored Cross-Site Scripting (XSS) in osTicket via Vulnerable Bootstrap Tooltip Component

## Affected Versions

- **Tested and confirmed vulnerable:**
  - osTicket **1.18.2**
  - osTicket **1.18.3**

- **Affected version:** 
	- v1.10 - v1.17.8 (excluding)
	- v1.18 - v1.18.4 (excluding)

This component has been present in the osTicket codebase **since May 13, 2015**, as shown by:

- File: `scp/js/bootstrap-tooltip.js`
- Commit: `e5a28410ae7c238932eef07c2b3568da015a792c`

This commit is associated with osTicket release tags dating back to **version 1.10**, indicating that the vulnerable Bootstrap Tooltip component has been included across a wide range of osTicket releases over multiple major versions. This long-term inclusion strongly suggests that **many osTicket versions released over several years are affected**.

---

## 1. Overview

osTicket is a widely used open-source ticketing system that allows end users to submit rich HTML content and file attachments as part of ticket creation and replies.

osTicket defines three major categories of users:

- **Admin**
  - Full administrative access
  - Global configuration, users, roles, plugins
- **Agent**
  - Operational access to tickets
  - Can view, respond, transfer, close tickets
- **User (Client / End User)**
  - Can only access the client portal
  - Can create and view their own tickets

Any HTML content submitted by a **User** may later be rendered in the browser of an **Agent** or **Admin**, making client-side vulnerabilities particularly impactful.

---

## 2. Proof of Concept

First, authenticate using your end-user account and go to the ticket creation page.  
Then create a JavaScript file (ex: test.js) containing a payload. For example:
```javascript
alert(123);
```

Note: By default, osTicket allows ticket attachments **without file type restrictions**.

![Upload a JS file](images/upload_a_js_file.png)


Then submit the ticket by clicking on **“Create Ticket”** without providing any **“Issue Details”**.

The application will redirect us back to the ticket submission form with the error **“Issue Details is a required field”**.  
This page allows us to retrieve a download link for our JavaScript file (`test.js`) without actually submitting a ticket.

![Get direct link of our uploaded JS file](images/get_direct_link_of_our_uploaded_js_file.png)

![Content-Type of our uploaded JS file](images/content-type_of_our_uploaded_file.png)


Once you have obtained this link, return to the ticket submission form.  
Click on the HTML editor and paste this payload, replacing the `src` attribute of the `script` tag with the link obtained earlier.

```html

">

```


Below is an example of a complete payload, where the `[LINK_HERE]` pattern has been replaced with the link obtained earlier:
```html

">

```


Then submit the ticket.

![Content-Type of our uploaded JS file](images/content-type_of_our_uploaded_file.png)

![Submit malicious payload](images/content-submit_malicious_payload.png)



When an administrator or agent views our malicious ticket, the payload is triggered.

![Payload triggered](images/payload_triggered.png)

**Result:**  
When an administrator/agent open the malicious ticket, the JavaScript payload is loaded and executed in the context of the admin/agent session.

This results in a **stored XSS**, allowing full session compromise (e.g. via ezXSS, CSRF to perform admin/agent actions).

---

## 3. Impact

### Agent Compromise

If the malicious ticket is viewed by an **Agent**, the stored XSS executes in the context of the Agent’s authenticated session.

This enables an attacker to effectively **take over the Agent session without needing to extract the session cookie** (e.g., even in scenarios where cookie exfiltration is not practical and a blind-XSS platform such as ezXSS is used). Once the XSS runs, the attacker can perform **any action the compromised Agent is allowed to perform**, for example:

- Consult tickets accessible to that Agent (often including a large portion of the helpdesk)
- Download and review ticket attachments
- Reply to tickets and interact with users
- Transfer, close, or otherwise update ticket state
- Add internal notes (if permitted)

This results in a full compromise of the Agent’s operational capabilities and the confidentiality/integrity of the ticketing workflow.

### Administrator Compromise

If the malicious ticket is viewed by an **Administrator**, the impact escalates to a full application compromise. The attacker can:

- Take over the Administrator session
- Modify **global configuration** (settings, permissions, ...)
- Trigger a **denial of service** by altering critical configuration values
- Modify administrative “pages” / templates, enabling **global defacement** and phishing on the application UI
- Create new **Agent** and/or **Administrator** accounts to establish persistence


### Note About Restricted File Upload and Content Security Policy

Although the default configuration of osTicket allows JavaScript file uploads, osTicket can be configured in the Admin Panel so that an end user is not allowed to upload JavaScript files.

Morerover, the Staff Control Panel used by agents and administrators enforces a Content Security Policy that prevents the execution of JavaScript originating from third-party domains.  
Let’s take the following payload as an example:

```html

">

```

The screenshot below shows that loading a script from https://evil.com was blocked by the Content Security Policy enforced on the Staff Control Panel.

![Payload blocked by CSP](images/payload_blocked_by_csp.png)


However, the Content Security Policy implemented on the application allows inline JavaScript.

![CSP on Agent/Admin Panel](images/csp_on_admin_panel.png)

In the case where JavaScript file uploads are blocked, it is still possible for an attacker to perform malicious actions. Let’s consider the payload below:

```html

">

```

The Base64 payload decodes to:
```html
top.location = "https://example.com";
```


This payload allows an attacker to redirect an agent or administrator viewing the malicious ticket to an arbitrary website, for example a phishing site.

Here is the result after viewing a ticket containing the payload above.
![Redirect to arbitrary website](images/redirect_to_example.png)