Password policy validate API called with empty password after successful password change

Steps to reproduce

1. Log in as an LDAP user
2. Go to personal settings → Security → Change password
3. Fill in current password and a valid new password (meeting all policy requirements)
4. Submit the form

Expected behaviour

Password is changed successfully and no error message is shown to the user.

Actual behaviour

Password is changed successfully on the server, but immediately after the successful change, the frontend calls /ocs/v2.php/apps/password_policy/api/v1/validate with an empty password (password: ""), causing a misleading error message:

"The password must be at least 10 characters long. The password is present in the list of compromised passwords."

The password IS changed correctly — the error message is false and confusing for end users.

Server configuration

Docker image: Nextcloud 33.0.2
Database: MariaDB 11.4
Password policy app version: 5.0.0
LDAP user and group backend version: 1.24.0

List of activated apps

Relevant apps:
password_policy: 5.0.0
user_ldap: 1.24.0

Nextcloud configuration

Authentication backend: OpenLDAP (user_ldap)
LDAP password changes enabled via: "Enable LDAP password changes per user"

Browser

Browser name: Chrome
Browser version: 147
Operating system: Android

Browser log

Network trace (browser devtools):

1. POST /index.php/settings/users/{user}/changepassword → payload: {oldpassword: "***", newpassword: "***"} → success ✓
2. POST /ocs/v2.php/apps/password_policy/api/v1/validate → payload: {password: ""} ← empty string, triggered after UI resets the field,fails ✗

Server log confirms the validate call is made with the authenticated user after the password was already changed successfully. The validate endpoint receives an empty password because the UI has already cleared the input field after the successful changepassword response.

Start with the change-password UI flow and the POST requests described in the report, especially /index.php/settings/users/{user}/changepassword and /ocs/v2.php/apps/password_policy/api/v1/validate. Trace what happens after a successful password change and confirm that the validation request is not sent with an empty password; the misleading error should no longer appear after a successful change.