CVE-2026-78357 in OTRS
Summary
by MITRE • 10/12/2026
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
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/12/2026
The vulnerability in question represents a critical failure in session management and token lifecycle control within the OTRS ticketing system, specifically affecting versions ranging from 7.0.X through to pre-2026.7.X releases. At its core, this is an issue of insufficient revocation mechanisms for JSON Web Tokens (JWTs). When an administrator deactivates a user account or changes a user's password, the expectation in secure systems is that all active sessions associated with that identity are immediately terminated to prevent unauthorized access. However, due to the stateless nature of JWTs and the specific implementation choices made by OTRS, previously issued tokens remain valid until their predefined expiration time elapses. This window can be as long as sixteen hours, creating a significant period during which an attacker who has already captured a token retains full operational privileges despite the account being effectively disabled or secured with a new credential.
From a technical perspective, this flaw stems from the lack of server-side validation against a revocation list or database check for each incoming JWT request. While modern authentication frameworks often implement short-lived access tokens paired with refresh tokens that are validated on every use, OTRS appears to rely solely on the cryptographic signature and expiration claim within the token itself without cross-referencing user status in real-time. This design decision prioritizes performance by avoiding database lookups for every API call but inadvertently sacrifices security immediacy. The result is a classic case where the system trusts the token's internal validity over the current state of the associated user account, allowing stale credentials to function as valid keys long after they should have been rendered useless.
The operational impact of this vulnerability is severe and directly tied to the privilege level of the compromised token. If an attacker obtains a customer user JWT, they can continue to access ticketing features, view sensitive information, or interact with other customers according to that specific role's permissions. More critically, if the stolen token belongs to an agent account, particularly one with administrative rights, the attacker maintains full control over the system. This includes the ability to create new tickets, modify existing ones, export customer data, and potentially escalate privileges further depending on the configuration. The persistence of access for up to sixteen hours provides a wide attack window that is difficult to detect in real-time, as standard login logs may not immediately reflect the abuse since the token itself appears legitimate to the application logic.
This vulnerability aligns with CWE-613, which describes insufficient session expiration, and more specifically relates to CWE-284, improper access control, where the system fails to enforce proper restrictions on an authorized user's actions after their authorization status has changed. In terms of the MITRE ATT&CK framework, this behavior facilitates persistence through valid credentials (T1078) and allows for lateral movement within the application environment if agent tokens are compromised. It also complicates incident response efforts because simply changing a password or disabling an account does not immediately neutralize the threat actor's access, requiring additional manual intervention such as forcing logout of all sessions or implementing token blacklisting mechanisms that may not be natively supported in older versions.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. For organizations running affected versions, the primary recommendation is to upgrade to version 2026.7.X or later where this issue has been resolved by implementing proper token invalidation logic upon account deactivation or password change. In environments where upgrading is not immediately feasible, administrators should consider reducing the JWT expiration time if configurable options exist within their specific OTRS deployment settings, thereby shrinking the window of opportunity for attackers. Additionally, deploying a Web Application Firewall (WAF) with rules that detect anomalous behavior patterns associated with stale tokens can provide an additional layer of defense. It is also crucial to enforce strict access controls and monitor user activity logs closely during any incident response scenario involving compromised credentials, ensuring that all active sessions are manually terminated via administrative tools if available, rather than relying solely on the application's automatic session management features.