CVE-2026-72632 in Kibana
Summary
by MITRE • 08/13/2026
Observable Discrepancy (CWE-203) in Kibana Fleet can lead to information disclosure via Excavation (CAPEC-116). Fleet removes the Elasticsearch API key value of an enrolled Elastic Agent from the responses of its agent listing capability, but that capability accepted caller-supplied filter expressions over the stored field that holds the value, and evaluated them with Kibana's own internal Elasticsearch privileges rather than the caller's. Because the number of matching agents is reported back to the caller, the difference between a matching and a non-matching filter formed a side channel from which the full API key value could be reconstructed one character at a time with a short sequence of requests.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/13/2026
The vulnerability described represents a classic example of an information disclosure flaw that leverages subtle implementation details to bypass intended security controls. This issue manifests within Kibana Fleet's agent listing functionality where the system attempts to protect sensitive API key values by redacting them from response data. However, the design contains a critical oversight that creates an exploitable side channel through which attackers can reconstruct the complete API key value despite the redaction mechanism. The vulnerability falls under CWE-203, which specifically addresses observable discrepancies that can reveal information about system internals or sensitive data.
The technical implementation flaw stems from how Kibana Fleet processes filter expressions submitted by callers when querying agent listings. While the system correctly removes the actual API key value from response payloads, it fails to properly validate or sanitize the filter parameters themselves. The system accepts arbitrary filter expressions that are then processed using Kibana's internal Elasticsearch privileges rather than the caller's actual permissions. This privilege separation creates a scenario where attackers can craft filter queries that produce different response counts based on whether specific characters of the API key match their guesses, effectively using the count difference as a binary indicator.
The operational impact of this vulnerability extends beyond simple information disclosure to represent a significant security risk for systems relying on Kibana Fleet for agent management. Attackers exploiting this weakness can systematically reconstruct complete API keys through a series of carefully crafted requests that exploit the side channel created by response count variations. The technique described as "excavation" or CAPEC-116 demonstrates how seemingly innocuous query parameters can be weaponized to extract sensitive information through indirect means. This attack pattern is particularly dangerous because it requires minimal privileges and can be executed repeatedly without alerting security monitoring systems.
The vulnerability highlights a fundamental principle in secure system design that emphasizes the importance of considering all potential information flows, including those that might not appear directly related to data access. The flaw demonstrates how the interaction between different privilege layers and filtering mechanisms can create unexpected attack surfaces. From an ATT&CK perspective, this vulnerability maps to techniques involving credential access through information gathering and reconnaissance activities, as attackers systematically extract sensitive credentials from the system. Organizations using Kibana Fleet should implement immediate mitigations including proper input validation for filter expressions, enforcement of caller privileges during filter evaluation, and enhanced monitoring for unusual query patterns that might indicate exploitation attempts.
The remediation approach should focus on strengthening the privilege model implementation within Kibana Fleet's agent listing functionality. This involves ensuring that all filter expressions are properly validated against the caller's actual permissions before processing, eliminating the possibility of attackers using response count differences as information sources. Additionally, the system should implement more robust rate limiting and query complexity controls to prevent automated exploitation attempts. The fix must also include proper logging and monitoring of filter operations to detect potential exploitation attempts, while maintaining the core functionality that allows legitimate users to search and manage agents effectively. Organizations should consider implementing additional security controls such as API key rotation procedures and enhanced access controls to minimize the impact if similar vulnerabilities are discovered in other system components.