Description

LogicalDOC Community Edition through 9.3 contains an improper authorization vulnerability in the PswRecovery servlet that fails to bind password recovery tickets to the requesting user. Attackers can obtain a ticket for their own account and reuse it with any userId, including administrators, to reset victims' passwords, lock them out, and reveal their email addresses.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.3",
  "pubDate": "2026-10-12T14:17:11.123Z",
  "pubdate": "2026-10-12T14:17:11.123Z",
  "executiveSummary": "LogicalDOC Community Edition through version 9.3 suffers from an improper authorization vulnerability within the PswRecovery servlet.\nThe flaw stems from a failure to correctly bind password recovery tokens to the identity of the user who requested the password reset.\nThis vulnerability allows an unauthenticated or authenticated attacker to perform an account takeover of any system user, including accounts with administrative privileges.\nBy generating a valid password reset ticket for their own account, an attacker can manipulate the request parameters to target arbitrary victim user IDs.\nSuccessful exploitation results in full account compromise, unauthorized password resets, denial of service via account lockout, and the exfiltration of sensitive user information such as registered email addresses.\nThe risk is critical as it bypasses standard authorization controls governing password recovery workflows.",
  "technicalDetails": "The vulnerability resides within the PswRecovery servlet, which handles the lifecycle of password reset requests in LogicalDOC Community Edition.\nThe root cause is a deficiency in the internal token validation logic. Specifically, the application fails to establish a cryptographically enforced binding between a generated password recovery ticket and the corresponding userId that initiated the request.\nIn a secure implementation, the system must ensure that the ticket stored in the backend is exclusively associated with the user account for which the reset was triggered. In this instance, the servlet lacks this server-side verification, treating the ticket as a generic key rather than a user-specific credential.\nThe attack flow follows a predictable sequence: First, the attacker initiates a legitimate password recovery process for their own controlled account, receiving a valid ticket generated by the PswRecovery servlet.\nSecond, the attacker intercepts or identifies the request structure used during the password reset validation phase. By modifying the parameters to substitute their own userId with the target victim's userId while retaining the validly issued ticket, the attacker forces the application to authorize the password change for the victim's account.\nBecause the server does not validate the association between the ticket and the account during the submission of the new password, the application accepts the request as legitimate. This allows the attacker to redefine the credentials for any user account present in the system.\nThe impact is severe; by resetting the password of an administrator, the attacker gains full control over the LogicalDOC instance. Furthermore, the exploitation process often returns metadata associated with the target user, allowing for the unauthorized disclosure of private email addresses. No special privileges are required to initiate the initial ticket request, and the attack can be performed over the network via standard HTTP/HTTPS requests directed at the servlet."
}