Kibana CVE-2026-78603

The attacker must hold a valid Kibana account with at least minimal Elasticsearch privileges - confirmed by the CVSS PR:L metric. The exposed data is specifically Fleet deployment metadata from the default Kibana space; Kibana instances where Fleet is not used or Elastic Agent is not deployed would expose no meaningful data through this path. No special network position, timing, race condition, or additional configuration is required beyond a valid low-privilege credential. Exploitation is limited by the authentication requirement (unauthenticated external parties cannot exploit this), by the read-only and narrow scope of the leaked data (Fleet metadata only, not arbitrary index data or credentials), and by the restriction to the default Kibana space (other spaces are not identified as affected). Deployments where every Kibana user is already a trusted internal operator with no need for Fleet access segregation face near-zero incremental risk.

The CVSS 4.3 Medium rating with vector AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N is well-calibrated for this vulnerability. The attack is trivially executable once the attacker holds any valid Kibana/Elasticsearch credential (PR:L), but the payoff is narrow: read-only access to Fleet deployment metadata - agent counts, policy assignments, and infrastructure topology - rather than credentials, user data, or arbitrary index content. No EPSS score is available in the provided data; combined with no KEV listing and no known public exploit, real-world exploitation probability appears low. The 'Authentication Bypass' tag in the input is inaccurate - the attacker remains authenticated and bypasses the authorization layer only, not the authentication layer; this misclassification could cause teams to overestimate severity. The primary elevated risk context is multi-tenant Kibana deployments where Spaces are used as a hard security boundary between teams, and where internal users with low-privilege accounts should not see Fleet infrastructure details. Single-tenant or internally-trusted deployments face near-zero incremental risk.

An authenticated Kibana user with only baseline Elasticsearch read privileges directly calls the Fleet metadata API for the default Kibana space - the same request a Fleet administrator would make. Because the server-side Kibana authorization check is absent, the request is processed and returns Fleet deployment metadata including agent policy assignments and infrastructure layout details, giving the attacker a reconnaissance view of Elastic Agent deployment topology. No public exploit code exists, but the attack requires only knowledge of Kibana's documented Fleet API paths and a valid low-privilege credential.