osTicket CVE-2026-38447

Exploitation requires the target osTicket instance to have the REST API enabled and at least one API key generated by the vulnerable 1.18.3 routine, and the attacker must be able to bound the key's creation time and know the client IP address recorded at generation - both feed directly into the MD5 input. Success is further gated by the strength of the nested md5(Misc::randCode(16)) component: if that random value is high-entropy, brute-forcing becomes infeasible despite the predictable time/IP inputs, which is the primary limiting factor. No user interaction or authentication is needed to submit guessed keys, but exploitation is meaningless on instances that expose no API keys or that firewall the API endpoint.

Signals conflict. The reporter's CVSS 9.8 (AV:N/AC:L/PR:N/UI:N, C/I/A:H) and the SSVC rating (automatable=yes, technical impact=total) argue for high priority, yet SSVC exploitation is 'none', there is no CISA KEV listing, no EPSS score was provided, and no working exploit code was supplied - only a disclosure write-up. A key caveat undercuts the CVSS complexity rating: the MD5 input also includes md5(Misc::randCode(16)), a nested random component; if randCode is a strong RNG this adds substantial entropy and real-world brute-forcing would be far harder than AC:L implies, pushing practical complexity toward AC:H. The genuine attack feasibility therefore hinges on (a) how weak Misc::randCode actually is and (b) the attacker's ability to bound the creation timestamp and know the originating IP - none of which is confirmed in the provided data. Treat this as a real design weakness worth patching, but the 9.8 likely overstates unconditional exploitability; verify the randCode entropy before treating it as trivially brute-forceable.

An attacker who can cause or observe API key creation (or estimate when an admin generated one) notes the likely creation timestamp and the client IP used, then computes candidate MD5 keys across that timestamp window and any weakly-random component and submits them to the osTicket API until one authenticates. With a valid key the attacker interacts with the ticketing API to create or manipulate tickets and access ticket data. A public exploit is not identified, but a technical disclosure write-up documenting the weakness exists.