TL;DR: osTicket 1.18.3 generates API keys using an MD5 hash of predictable inputs: the current timestamp, the client IP address, and a constant seed. An attacker who can approximate the key generation time can brute-force the key space within a feasible window. Those API keys grant full access to the ticketing system. CVSS 9.8. Fixed in the latest commit on the main branch.

What is osTicket

osTicket is the most widely deployed open-source help desk and support ticketing system. It routes inquiries from email, web forms, and phone into a unified queue, and it runs on PHP with MySQL. The project reports 5 million users worldwide across more than 15,000 businesses. Companies tracked by Enlyft include NetApp, Fraunhofer, and government organizations using .gov domains.

osTicket's API layer allows external systems to create tickets, fetch customer data, and manage the support workflow programmatically. API keys are the only credential for that layer. There is no OAuth, no short-lived token rotation, no secondary factor. The key alone is the authentication boundary.

How big is the impact

The CVSS 9.8 score is appropriate: network-reachable, no authentication, no user interaction, and complete compromise. An attacker who derives a valid API key can read all tickets (including internal notes and attachments containing sensitive customer data), create fake tickets, modify ticket statuses, extract customer contact lists, and close or delete support requests.

The brute-force is feasible because MD5 is fast and the inputs are low-entropy. The attacker only needs to guess the timestamp of key generation within a few seconds. If the key was generated during a known window (for example, immediately after an administrator account was created), the search space shrinks dramatically. A single valid key unlocks the entire API for that osTicket instance.

For the 15,000 organizations running osTicket, this means every API key ever generated on version 1.18.3 and earlier is cryptographically weak. Rotating keys is not enough if the generation algorithm remains the same. The fix must change how keys are produced.

What happened

The key generation logic lives in include/class.api.php and calls into a utility function in include/class.misc.php. It concatenates the current timestamp, the requesting IP address, and a fixed seed string, then passes the result through md5(). The output is used as the API key. MD5 is not a key derivation function, and the inputs are predictable or observable. The timestamp can be inferred from HTTP Date headers. The IP address is visible in server logs or can be approximated. The seed is static.

The fix, committed in feccb6a, replaces the MD5-based construction with a cryptographically secure random string generator. Keys are now 32-character hex strings drawn from a CSPRNG, making them infeasible to predict.

What to do

Update osTicket to include the fix commit feccb6a or later:

git clone https://github.com/osTicket/osTicket.git
cd osTicket
git checkout feccb6a3a90863fd31215ee738b39762177e658c

After updating, generate new API keys for every user and service account in your osTicket instance. Revoke and delete all existing keys immediately. Audit your API access logs for any unusual activity: bulk ticket exports, unexpected ticket creation, or access from unfamiliar IP addresses. Treat every key created before the fix as potentially compromised.

• Full CVE Disclosure
• osTicket on GitHub
• osTicket Website