CVE-2026-92467 in microservices-platform
Summary
by MITRE • 09/16/2026
zlt2000 microservices-platform through 6.0.0 contains an unverified password change vulnerability in the PUT /users/password endpoint that allows authenticated users to change any account password by omitting the current password check. Attackers can supply an arbitrary user id in the request body and a new password to overwrite credentials of any non-administrator account without verification.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/16/2026
The zlt2000 microservices-platform, specifically versions through 6.0.0, contains a critical authentication bypass vulnerability within its user management module. This flaw is located in the PUT /users/password endpoint and represents an insecure direct object reference combined with insufficient verification of credentials during sensitive state changes. The core technical failure lies in the backend logic which processes password update requests without validating that the requester possesses knowledge of the current password for the target account. While the platform requires authentication to access this endpoint, it fails to enforce a secondary proof-of-possession mechanism, such as requiring the user to input their existing password before allowing a change. This design oversight allows any authenticated session to manipulate credential data for other users by simply supplying an arbitrary user identifier in the request body alongside the desired new password value.
From a technical perspective, this vulnerability exploits the lack of authorization checks and validation controls during account modification operations. The application trusts the client-side provided user ID without cross-referencing it against the identity associated with the active authentication token or session context. Consequently, an attacker who has obtained valid credentials for any low-privilege account can craft a malicious HTTP PUT request targeting this endpoint. By replacing the intended target identifier with that of another non-administrator user and submitting a new password payload, the server processes the update without verifying ownership of the original credentials. This behavior aligns directly with CWE-284, which describes Improper Access Control where insufficient restrictions are applied to unauthorized actions, as well as CWE-640, Weak Password Change Mechanism, indicating that the system does not adequately verify the identity of the user initiating a password change.
The operational impact of this vulnerability is severe for any organization relying on zlt2000 microservices-platform for internal or external services. An attacker can perform unauthorized account takeover by resetting passwords for other non-administrator accounts without needing to guess or brute-force existing credentials. This capability facilitates lateral movement within the network, as compromised low-privilege accounts can be used to access sensitive resources, exfiltrate data, or pivot to higher-value targets if privilege escalation paths exist elsewhere in the architecture. Furthermore, this flaw undermines the integrity of audit trails and accountability measures since actions taken under a victim account are indistinguishable from legitimate user activity unless detailed logging is implemented at the database level. In terms of threat modeling, this technique corresponds to ATT&CK T1078 Valid Accounts, where adversaries use valid credentials to gain access, and specifically relates to credential manipulation tactics that allow persistent unauthorized access without detection by standard authentication monitoring systems.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. The most effective solution is to implement a mandatory current password verification step in the PUT /users/password workflow before any changes are committed to the database. This ensures that only users who know their existing credentials can modify them, thereby enforcing proper ownership validation. Additionally, developers should enforce strict object-level authorization checks by binding the user ID parameter directly to the authenticated session’s principal identity rather than accepting it from the request body. Input validation routines must be strengthened to reject any discrepancies between the target account identifier and the requesting user’s profile data. For organizations unable to immediately patch this issue due to legacy constraints, network segmentation can limit exposure of internal microservices endpoints, while Web Application Firewalls may offer partial protection by inspecting PUT requests for anomalies in parameter patterns, though such controls are not a substitute for fixing the underlying logic flaw. Regular security code reviews focusing on authentication and authorization flows across all API endpoints are recommended to prevent similar vulnerabilities from being introduced during future development cycles.