CVE-2026-92468 in microservices-platform
Summary
by MITRE • 09/16/2026
zlt2000 microservices-platform through 6.0.0 contains an authorization bypass vulnerability in the search-center service that allows authenticated attackers to read any Elasticsearch index by specifying the index name in POST /search/{indexName} and GET /agg/requestStat/{indexName}/{routing} path variables. Attackers can query arbitrary indices including sys_user to retrieve sensitive user records and password hashes without proper access controls.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/16/2026
The zlt2000 microservices-platform, specifically within the search-center service up through version 6.0.0, suffers from a critical authorization bypass vulnerability that undermines the fundamental security model of the application. This flaw stems from an improper implementation of access control mechanisms when handling requests directed at Elasticsearch indices. The system relies on path variables to determine which data source is being accessed, yet it fails to validate whether the authenticated user has legitimate permissions to interact with the specific index identified in the request URL. Consequently, any attacker who possesses valid credentials for a low-privileged account can manipulate these parameters to access resources that are strictly intended for administrative or restricted use only. This represents a classic case of broken object level authorization where the application trusts client-supplied input regarding resource identity without performing adequate server-side permission checks against the user's role and privileges.
The technical mechanism of this exploitation involves targeting specific endpoints within the search-center service, namely POST /search/{indexName} and GET /agg/requestStat/{indexName}/{routing}. By injecting arbitrary index names into these path variables, an attacker can direct queries to any Elasticsearch index present in the cluster environment. The vulnerability allows for unrestricted read access, meaning that sensitive data stored in these indices becomes fully retrievable by unauthorized parties. This is particularly dangerous because it bypasses standard authentication and authorization layers, effectively treating all authenticated users as having global read privileges across the entire search infrastructure. The lack of validation on the index name parameter creates a direct path to information disclosure without requiring privilege escalation or exploitation of other complex vulnerabilities in the system architecture.
The operational impact of this vulnerability is severe due to the nature of the data typically stored in Elasticsearch indices within enterprise microservices environments. Attackers can target sensitive internal tables such as sys_user, which often contains user profiles, email addresses, and critically, password hashes. The retrieval of these records allows for offline cracking attempts against captured credentials, potentially leading to further compromise of higher-privileged accounts if weak hashing algorithms or reused passwords are in place. Beyond credential theft, the ability to query arbitrary indices may expose other sensitive business data depending on how the platform is configured, including personal identifiable information, transaction logs, or configuration details that could aid in subsequent attacks such as lateral movement within the network. This vulnerability effectively neutralizes the confidentiality guarantees provided by the application's security controls for any data stored in accessible Elasticsearch clusters.
From a classification perspective, this issue aligns with CWE-284 Improper Access Control and specifically CWE-639 Authorization Bypass Through User-Controlled Key. In terms of offensive tactics, it maps to ATT&CK technique T1078 Valid Accounts, as the attacker leverages legitimate credentials to access unauthorized resources, and potentially T1005 Data from Local System if the Elasticsearch instance is local or closely coupled with other sensitive data stores. To mitigate this risk, developers must implement strict allow-listing for index names rather than relying on blacklisting approaches which are prone to bypasses. Input validation should be enforced at the service layer to ensure that only pre-approved indices can be queried by specific user roles. Additionally, integrating Elasticsearch's native security features such as role-based access control with field-level permissions provides a defense-in-depth strategy. Regular security audits and static code analysis focused on authorization logic are recommended to identify similar patterns in other services within the microservices architecture before they can be exploited in production environments.