CVE-2026-78358 in OTRSinfo

Summary

by MITRE • 10/12/2026

Several administrative actions do not sufficiently validate whether a request was intentionally initiated by the authenticated user. In particular, the DBUpdateLogCleanUp action can be triggered through a GET request without validating a ChallengeToken. An unauthenticated remote attacker can therefore cause the browser of an authenticated administrator to execute the cleanup action by embedding a crafted request in a malicious web page. Successful exploitation can delete existing DBUpdate log entries. This may reduce the availability of diagnostic and historical information used for troubleshooting and auditing. The impact is limited to DBUpdate log entries that exist at the time the forged request is processed.

Additional administrative endpoints were identified that do not validate a ChallengeToken. Some of these endpoints can trigger administrative actions such as deploying or synchronizing already existing configuration. They do not allow an attacker to introduce arbitrary new configuration through the CSRF request itself. 

Export and read-only endpoints were also identified without ChallengeToken validation. While these endpoints may be triggered through a forged cross-site request, the response content remains subject to the browser's same-origin restrictions and is not automatically exposed to the attacker. Therefore, no direct confidentiality impact has been demonstrated for these endpoints.

This issue affects OTRS:

* 7.0.X * 8.0.X * 2023.X * 2024.X * 2025.X * 2026.X before 2026.7.X

Please note that ((OTRS)) Community Edition 6.x and before are vulnerable. Products based on the ((OTRS)) Community Edition also very likely to be affected

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Analysis

by VulDB Data Team • 10/12/2026

The identified vulnerability represents a critical failure in cross-site request forgery protections within the administrative interface of OTRS, specifically affecting versions from the 7.0.X series through the upcoming 2026.X releases prior to version 2026.7.X. The core technical flaw lies in the insufficient validation of user intent for several administrative actions. In secure web application design, state-changing operations must require explicit confirmation that the request was initiated by a legitimate, authenticated user and not coerced from another context. This vulnerability arises because specific endpoints fail to validate a ChallengeToken, which is typically used as an anti-CSRF measure to ensure session integrity. By omitting this validation step for certain administrative functions, the application inadvertently allows attackers to craft malicious requests that are executed with the privileges of any logged-in administrator who visits a compromised page.

The most significant impact stems from the DBUpdateLogCleanUp action, which can be triggered via a simple GET request without requiring a ChallengeToken. This design flaw enables an unauthenticated remote attacker to execute cross-site request forgery attacks against authenticated administrators. By embedding a crafted URL pointing to this endpoint within a malicious web page or email link, an attacker can trick an administrator into visiting the site while their session is active in another tab or window. Upon loading the malicious content, the browser automatically sends the administrative cleanup request along with any stored authentication cookies. The successful exploitation of this vector results in the deletion of existing DBUpdate log entries from the database. This action directly compromises the availability and integrity of diagnostic data, as these logs are essential for troubleshooting system issues, tracking configuration changes, and maintaining an audit trail of historical events.

Beyond the immediate loss of logging data, the absence of ChallengeToken validation extends to other administrative endpoints that perform sensitive operations such as deploying or synchronizing existing configurations. While these specific actions do not allow an attacker to inject arbitrary new configuration parameters directly through the CSRF payload, they still pose a risk by allowing unauthorized execution of state-changing commands like synchronization processes. This can lead to unintended system behavior, potential service disruptions during deployment cycles, or the overwriting of current settings with previously saved states that may no longer be appropriate for the current operational context. The ability to trigger these actions without proper authorization checks undermines the principle of least privilege and exposes the administrative infrastructure to manipulation by external actors who have successfully lured an administrator into a malicious environment.

It is important to distinguish this vulnerability from cross-site scripting or data exfiltration attacks regarding read-only endpoints. While export and read-only functions were also identified as lacking ChallengeToken validation, they do not present a direct confidentiality risk in the same manner. Because these endpoints only retrieve information rather than modify state, any response content generated by a forged request remains subject to the browser's same-origin policy restrictions. Consequently, even if an attacker triggers such a request from their malicious page, they cannot automatically access or read the returned data due to security boundaries enforced by modern web browsers. Therefore, while these endpoints are technically vulnerable to CSRF execution, the practical impact is limited to potential denial of service through resource consumption rather than unauthorized data disclosure.

The scope of this vulnerability encompasses OTRS versions 7.0.X, 8.0.X, and all subsequent releases up to but not including 2026.7.X. Additionally, products based on the OTRS Community Edition version 6.x and earlier are also considered vulnerable due to shared architectural patterns in their authentication and session management mechanisms. This widespread impact highlights a systemic issue within these versions of the software where security controls for administrative actions were inconsistently applied across different modules. Organizations running affected versions must prioritize remediation to restore trust in the integrity of their IT service management processes and ensure that audit logs remain intact for compliance and operational purposes.

From a classification perspective, this vulnerability aligns with CWE-352, which describes Cross-Site Request Forgery (CSRF). The lack of anti-CSRF tokens or equivalent mechanisms allows attackers to bypass authentication checks by leveraging the victim's active session. In terms of offensive security frameworks, this technique corresponds to ATT&CK tactic T1078, specifically relating to Valid Accounts and potentially T1566 if phishing is used as a delivery vector for the malicious page containing the forged request. The exploitation relies on social engineering or compromised websites to induce an authenticated user to initiate unintended actions, exploiting the trust relationship between the browser and the web application.

Mitigation strategies should focus on implementing robust anti-CSRF protections across all administrative endpoints that modify system state. This includes enforcing strict ChallengeToken validation for every POST, GET, PUT, DELETE, or PATCH request that alters database content or configuration settings. Developers must ensure that sensitive actions are not exposed via simple GET requests without additional verification layers such as double-submit cookies or synchronized tokens. For administrators unable to immediately patch the software, network-level controls can provide temporary relief by restricting access to administrative interfaces based on IP whitelisting or requiring multi-factor authentication for all login sessions. Regular auditing of web application firewalls and intrusion detection systems should also be conducted to identify patterns consistent with CSRF exploitation attempts targeting these specific endpoints.

Responsible

OTRS

Reservation

08/24/2026

Disclosure

10/12/2026

Moderation

accepted

EPSS

0.00000

KEV

no

Activities

low

Sources

Want to know what is going to be exploited?

We predict KEV entries!