Kibana CVE-2026-78597

Exploitation requires an active, authenticated Kibana session scoped to at least low-privilege Security feature access - a standard user account assigned to the Kibana Security application suffices. The Kibana Security feature, which includes Entity Store, must be enabled; this is the expected configuration in security-focused Elastic Stack deployments (SIEM, threat detection). No elevated OS privileges, special network position, or non-default Kibana configuration is needed beyond this baseline. Limiting factors: the attacker must possess a valid Kibana credential, ruling out unauthenticated external actors; and the API keys are created under the attacker's own low-privilege identity rather than granting arbitrary administrative control, so further exploitation depends on what that identity can access via direct Elasticsearch API calls.

The vendor CVSS score of 4.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N) captures network-accessible exploitation by an authenticated low-privilege user but assigns I:N, which understates real-world impact: unauthorized creation of persistent Elasticsearch API keys is an integrity violation - those credentials exist beyond the Kibana session and could be leveraged for direct Elasticsearch access that circumvents Kibana's access controls entirely. EPSS data is absent from the input; no CISA KEV listing exists, and no public exploit has been confirmed, indicating this is not under active widespread exploitation. Realistic risk is moderate-to-elevated for organizations where Kibana Security feature access is granted broadly: the prerequisite of a valid low-privilege account limits external attackers but makes insider abuse or post-compromise lateral movement a credible path. The integrity concern lifts practical priority above what the 4.3 score implies.

An attacker holding a routine low-privilege Kibana account with Security feature access sends a crafted HTTP request directly to the Entity Store initialization endpoint, bypassing the authorization check. The operation completes successfully, creating and persisting an Elasticsearch API key under the attacker's identity. The attacker then uses this API key to query Elasticsearch directly - outside Kibana's session and access controls - for as long as the key remains valid.