osTicket timing vulnerability: Understanding the risk

osTicket password reset endpoint timing side‑channel enables user enumeration – CVE‑2026‑26895

Summary:

CSA Cyber identified a vulnerability within osTicket versions 1.18.2 and below, tracked under CVE-2026-26895. osTicket is an open-source support ticket system designed to help organisations manage customer service and IT support requests efficiently. It provides a centralised platform where users can submit tickets via email, web forms, or phone, whilst support teams can track, prioritise, and resolve issues accordingly. The vendor has released a fix addressing the reported vulnerability, and version 1.18.3 is no longer affected.

Technical details

A vulnerability has been identified within the /pwreset.php page of the osTicket application. This issue manifests only after the SMTP (Simple Mail Transfer Protocol) email service has been configured and is not present prior to its setup. The vulnerability presents itself as a significant discrepancy in server response times when processing password reset requests for existing usernames compared to non-existent ones. This timing discrepancy enables an attacker to perform user enumeration via brute force, as valid usernames can be inferred based on response latency. Although the vulnerability does not directly expose credentials, it increases the risk of targeted attacks by allowing adversaries to compile a list of valid accounts.

Proof of concept:

Figure 1: Burp Suite Intruder results demonstrating the response time discrepancy between valid and non-existent usernames.

Demonstrating impact

The impact of this vulnerability lies in its ability to enable user enumeration through measurable differences in server response times. When the SMTP (Simple Mail Transfer Protocol) service is configured, the password reset functionality on /pwreset.php behaves differently depending on whether the submitted username exists: 

• Valid username: The application attempts to send a password reset email via SMTP (Simple Mail Transfer Protocol), resulting in a noticeably longer response time, typically several seconds.

• Invalid username: The application immediately returns an error without initiating email delivery, resulting in a considerably shorter response time, usually under one second. 

This discrepancy allows an attacker to automate requests and infer valid usernames by analysing response latency. Once valid usernames have been identified, they can be leveraged for credential stuffing, phishing, or brute-force attacks, significantly increasing the risk of account compromise.

Example attack flow using Burp Suite

To exploit this vulnerability, an attacker would perform the following steps: 

1. Prepare a list of common usernames the attacker compiles a list of potential usernames from sources such as:

• Public directories (e.g. LinkedIn, company websites).
• Previous data breaches.
• Common username patterns (e.g. jdoe, john.doe, j.doe).

For this demonstration, the list contains one thousand invalid usernames and one valid username. 

2. Capture the password reset request

• Navigate to /pwreset.php and submit a password reset request.
• Intercept the request using Burp Proxy and forward it to Burp Intruder. 

3. Configure Burp Intruder

• Set the payload position on the username parameter.
• Load the prepared username list into the payloads tab.
• Enable the response time column within the intruder results to measure latency.
• Select the sniper attack type for single-parameter testing. 

4. Launch the attack 

• Start the intruder attack to send sequential password reset requests for each username.
• Burp Suite will record response times for every request.

5. Analyse results and identify valid usernames review the intruder results as follows: 

• Longer response time (e.g. 4–5 seconds) → Username exists (SMTP email triggered).
• Shorter response time (e.g. <1 second) → Username does not exist.

Compile the identified valid usernames for use in targeted attacks.

Example intruder results table:

Impact

This timing discrepancy allows attackers to enumerate valid accounts with a high degree of confidence. Once valid usernames have been identified, an attacker may proceed with: 

• Credential stuffing using previously leaked passwords.
• Phishing campaigns targeting confirmed valid users.
• Brute-force login attempts against the application.

The consequences of these follow-on attacks can be severe for an organisation. A successful account compromise may result in:

• Data breaches: Exposing sensitive customer and employee data, potentially leading to regulatory penalties under frameworks such as GDPR or ISO 27001.
• Reputational damage: Loss of customer trust and confidence in the organisation's ability to safeguard their information.
• Operational disruption: Attackers gaining access to internal support systems may manipulate, delete, or exfiltrate tickets containing sensitive information.
• Financial impact: Costs associated with incident response, legal liability, regulatory fines, and potential compensation claims. 

Remediation

Following responsible disclosure by Ruben Ferreira of Cyber Security Associates, the osTicket development team addressed the vulnerability in commit d832f24, released as part of version 1.18.3 on 15th January 2026. The fix was implemented by developer JediKev and is described as a "password reset hardening" measure. 

The patch introduces a minimum response time on the /pwreset.php endpoint, regardless of whether the submitted username exists within the system. This was achieved by recording the start time of the request using microtime() and enforcing a minimum response threshold of 1.4 seconds, with a small random jitter of up to 250 milliseconds added to prevent statistical timing analysis. If the request completes before this threshold is reached, the application deliberately delays the response using usleep() to pad the remaining time. This ensures that both valid and invalid username requests return at a consistent and indistinguishable response time, effectively eliminating the timing discrepancy that enabled user enumeration. 

As of version 1.18.3, osTicket is no longer vulnerable to this attack. Organisations running version 1.18.2 or below are strongly advised to upgrade immediately. 

Disclosure timeline

15th January 2026: Vulnerability identified and reported to the vendor
15th January 2026: CVE request submitted
15th January 2026: A patch was released by the vendor to fix the vulnerability
24th February 2026: CVE ID CVE-2026-26895 received
1st April 2026: This blogpost published

The same‑day turnaround between reporting, CVE submission, and patch release reflects a highly efficient and collaborative disclosure process. The vendor acted rapidly to validate the finding and deploy a fix.