CVE-2026-119648 in BlueKing CMDB
Summary
by MITRE • 10/30/2026
Tencent BlueKing CMDB (bk-cmdb) through 3.14.6 contains a missing authorization vulnerability that allows authenticated users to view hosts of other businesses via POST /api/v3/hosts/search/asstdetail. Attackers can submit host search conditions targeting other businesses or omitting business filters to retrieve host attributes and topology association details, because the route is mapped to SkipAction and SearchHostWithAsstDetail skips AuthorizeSearchHost.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/30/2026
The vulnerability identified in Tencent BlueKing CMDB versions through 3.14.6 represents a critical failure in access control mechanisms within the configuration management database system. This flaw specifically affects the API endpoint POST /api/v3/hosts/search/asstdetail, which is designed to retrieve host attributes and topology association details for asset inventory purposes. The core issue stems from an improper implementation of authorization checks during request processing. Specifically, the route mapping for this endpoint incorrectly assigns it to SkipAction, a designation that bypasses standard security filters. Consequently, when the SearchHostWithAsstDetail function is invoked, it fails to execute AuthorizeSearchHost, which is the mandatory procedure responsible for validating user permissions against specific business units or resource scopes.
This architectural misconfiguration results in a missing authorization vulnerability where authenticated users can circumvent intended data isolation boundaries. In a properly secured environment, CMDB systems enforce strict separation of duties and data visibility based on organizational structures such as business lines or projects. However, due to the bypassed authorization logic, an attacker who has valid credentials for any user account within the system can manipulate search parameters to target hosts belonging to other businesses. By either explicitly specifying host search conditions that belong to a different tenant or simply omitting business filters entirely, the application returns sensitive infrastructure data without verifying if the requesting user possesses the requisite privileges for those specific resources.
The operational impact of this vulnerability is significant from both an intelligence gathering and potential exploitation perspective. The exposed information includes detailed host attributes and topology association details, which provide a comprehensive map of the internal network architecture. Attackers can use this data to identify critical servers, understand service dependencies, and locate high-value targets within the organization's infrastructure. This level of visibility facilitates further attack vectors such as lateral movement, privilege escalation, or targeted attacks against specific services running on those hosts. The ability to enumerate assets across business boundaries undermines the principle of least privilege and compromises the confidentiality of sensitive operational data managed by the CMDB.
From a classification standpoint, this vulnerability aligns with CWE-285 Improper Authorization, as the application fails to enforce appropriate access controls when an authenticated user attempts to access resources belonging to another entity. Additionally, it relates to CWE-732 Incorrect Permission Assignment for Critical Resource, given that the configuration management database is a critical asset containing sensitive infrastructure metadata. In terms of adversary tactics, this behavior corresponds to ATT&CK technique T1087.001 Account Discovery: Local Account, as attackers can enumerate local accounts and host information, and potentially T1592 Gather Victim Host Information by mapping the network topology through the exposed association details.
Mitigation strategies must focus on correcting the authorization logic within the application codebase. The immediate remediation involves ensuring that all API endpoints handling sensitive resource queries enforce strict permission checks before returning data. Specifically, the route for POST /api/v3/hosts/search/asstdetail should not be mapped to SkipAction but rather linked to a handler that invokes AuthorizeSearchHost or an equivalent authorization middleware. Developers must verify that business unit filters are mandatory and validated against the requesting user's assigned roles and permissions. Furthermore, input validation should ensure that omitted filters do default to restricting results only to resources explicitly owned by the authenticated user, thereby preventing cross-tenant data leakage. Regular security audits of API route configurations and permission mappings are recommended to prevent similar oversights in future updates or custom integrations.