osTicket EUVD-2026-51068

Exploitation requires the attacker to possess a valid, previously issued password-reset token for the target account - this is the concrete precondition encoded as AT:P in the CVSS 4.0 vector; the flaw specifically lets such a token bypass the configured validity-period (expiry) check because the expiry comparison only executes when the timestamp lookup fails. No login credentials (PR:N) and no victim interaction (UI:N) are needed once the token is held, and the reset endpoint is network-reachable. What limits exploitation: the attacker must acquire the token out-of-band (leaked email, logs, shared inbox, or interception) since the vulnerability does not itself generate tokens, and only osTicket instances before v1.17.8 / v1.18.4 are affected.

The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H) scores 9.1 Critical, reflecting network-reachable, unauthenticated exploitation with high confidentiality and integrity impact but no availability impact. The key tempering signal is AT:P (Attack Requirements: Present): exploitation is not fully autonomous because the attacker must first obtain a valid password-reset token, which is not guaranteed against a hardened target. No EPSS score was provided, KEV status is negative (not actively exploited per available data), and no POC is referenced - so despite the Critical rating this is not confirmed to be under active or widespread exploitation. The realistic risk is high where reset tokens can be intercepted, leaked (e.g., via referer headers, logs, or shared mailboxes), or where an old token can be reused, but the AT:P precondition means this is more plausible as targeted account takeover than mass, drive-by exploitation.

An attacker obtains a password-reset token for a target osTicket account - for example an old token that was emailed and never used, one exposed in logs or a shared support inbox, or one captured in transit - and submits it to the reset endpoint after its intended validity window has passed. Because the expired-token check is skipped whenever the token's timestamp exists, the stale token is accepted, letting the attacker set a new password and take over the account remotely without authentication. No public POC is currently identified, but the network vector and low attack complexity make exploitation straightforward once a token is in hand.