Description

Previously issued authentication tokens are not immediately invalidated when an OTRS agent or customer user account is deactivated or its password is changed. As a result, an existing JWT may remain valid until its regular expiration time, which can be approximately 16 hours. An attacker who has previously obtained a valid authentication token can therefore continue to access OTRS with the privileges of the affected agent or customer user even after the corresponding account has been deactivated or the user's password has been changed. The vulnerability does not allow an attacker to obtain authentication tokens by itself. Exploitation requires possession of a previously issued and still valid token. The actual impact depends on the privileges associated with the compromised token. Customer user tokens are limited to the permissions of the affected customer account, while agent tokens may provide access to broader ticket, customer, or administrative functionality depending on the assigned permissions. This issue affects OTRS: * 7.0.X * 8.0.X * 2023.X * 2024.X * 2025.X * 2026.X before 2026.7.X

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.1",
  "pubDate": "2026-10-12T07:16:37.073Z",
  "pubdate": "2026-10-12T07:16:37.073Z",
  "executiveSummary": "This vulnerability involves an improper authentication token revocation mechanism within OTRS, where JSON Web Tokens (JWTs) remain cryptographically valid despite changes to the underlying user account status. Because OTRS fails to invalidate existing sessions upon account deactivation or password modification, a stateless token remains operational until its predefined expiration time, which can extend up to 16 hours.\nThe flaw affects OTRS versions 7.0.X, 8.0.X, 2023.X, 2024.X, 2025.X, and versions of 2026.X prior to 2026.7.X. This security deficit allows an attacker possessing a previously intercepted or compromised valid token to maintain unauthorized access to the application, effectively bypassing administrative or customer-level security controls enforced on the account.\nThe risk implication is significant for environments where account lifecycle management is critical for security posture, as the revocation delay provides an exploitable window of opportunity. Successful exploitation requires the attacker to have already obtained a valid authentication token. No new tokens can be generated by an unauthorized party via this vulnerability; however, the persistence of the 'live' token ensures continued access to sensitive ticket data, customer information, or administrative functions based on the privileges associated with the original token holder.",
  "technicalDetails": "The root cause of this vulnerability lies in the implementation of the OTRS authentication service, which relies on the inherent stateless nature of JSON Web Tokens without an accompanying server-side blacklist or revocation state management system. During the OTRS authentication flow, a JWT is issued to the user containing claims that include user identity and associated permissions. Because these tokens are self-contained and signed by the server, the application validates them based solely on their cryptographic signature and standard claims (e.g., expiration time) during each request.\nWhen a security event occurs—such as a user account deactivation or a password change—the OTRS backend updates the primary user database. However, the authentication service does not synchronize these changes with the active JWT lifecycle. Consequently, there is no mechanism to invalidate existing tokens stored on the client side or to verify the current status of the user against an authoritative source at the time of token validation. This effectively creates an authentication 'grace period' that persists for the remainder of the token's TTL (Time-to-Live), which is configured for approximately 16 hours.\nThe exploitation flow is as follows: 1) An attacker intercepts a legitimate JWT belonging to an OTRS agent or customer through methods such as session hijacking, XSS, or network eavesdropping. 2) The authorized OTRS administrator detects a compromise or performs a routine account lifecycle action, such as disabling the account or resetting the credentials, believing this terminates the attacker's access. 3) The attacker, unaware of or unaffected by the account change, continues to present the existing JWT in HTTP headers for requests to OTRS endpoints. 4) The OTRS server's JWT middleware validates the token's signature, confirming it is cryptographically intact and not yet expired. 5) The server permits the request, granting the attacker access to the privileges associated with the target account.\nThe impact of this vulnerability is directly tied to the level of access the compromised token possessed at the time of issue. If the token belongs to an OTRS agent with administrative privileges, the attacker retains the ability to modify system configurations, manage tickets, or export sensitive customer data. Because the session remains 'authorized' until the 16-hour expiration threshold is reached, the window for unauthorized data exfiltration or administrative abuse remains open even after the legitimate user has been ostensibly blocked from the system."
}