Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.1",
  "pubDate": "2026-08-13T20:17:24.060Z",
  "pubdate": "2026-08-13T20:17:24.060Z",
  "executiveSummary": "An observable discrepancy vulnerability classified as CWE-203 exists in Kibana Fleet, potentially leading to unauthorized information disclosure via CAPEC-116 excavation techniques.\nThe vulnerability impacts Kibana Fleet by allowing attackers to exploit an information side channel through the agent listing capability.\nThe core risk involves the reconstruction of sensitive Elasticsearch API key values belonging to enrolled Elastic Agents.\nAttackers with the capability to submit specific caller-supplied filter expressions can leverage the discrepancy between matching and non-matching filter results.\nBy observing the reported count of matching agents in response payloads, an attacker can systematically reconstruct the full API key value one character at a time using a short sequence of crafted requests.\nThis flaw undermines confidentiality controls around privileged credentials stored within the Fleet management infrastructure.",
  "technicalDetails": "The root cause of the vulnerability lies in improper handling of caller-supplied filter expressions within the Fleet agent listing capability.\nAlthough Fleet successfully removes the Elasticsearch API key value of an enrolled Elastic Agent from the direct JSON output of agent listing responses, the underlying query execution path introduces a fatal flaw.\nThe listing capability accepts filter expressions targeting the stored field containing the sensitive API key value.\nCrucially, Fleet evaluates these user-supplied filter expressions using Kibana's internal Elasticsearch superuser or elevated privileges rather than restricting the evaluation to the querying caller's actual authorization context.\nBecause the agent listing capability reports the precise number of matching agents back to the caller, a timing or response-size oracle is established.\nThis creates an observable discrepancy side channel (CWE-203).\nAn attacker exploits this mechanism via excavation (CAPEC-116) by issuing a series of boolean or wildcard-based filter queries targeting the API key field.\nFor instance, by testing individual character ranges or specific string prefixes against the stored API key field, the attacker observes whether the agent count increments (indicating a match) or remains zero (indicating a non-match).\nThrough this iterative brute-forcing methodology, the complete Elasticsearch API key value can be reconstructed character by character with minimal request overhead.\nThe vulnerable component is the Fleet agent listing API and its associated filter evaluation logic within Kibana.\nExploitation requires the ability to interact with the Fleet agent listing endpoint, execute customized filter expressions, and observe the resulting match counts returned in the response payload."
}