Kibana CVE-2026-63259

Exploitation requires a valid, authenticated Kibana user account (PR:L per CVSS vector - unauthenticated exploitation is not possible). The attacker must know or successfully enumerate at least one object identifier for a scheduled query result residing in a different Kibana Space. The target Kibana deployment must be running version 9.4.0 through 9.4.3 and must have the Spaces feature in use with at least two Spaces, at least one of which contains scheduled query result data. Single-Space deployments have no exposure as cross-Space isolation is the attack precondition. What limits exploitation: valid credentials are mandatory, the data exposure is scoped to scheduled query results only (not full Elasticsearch index data), and the attacker must have prior knowledge of or the ability to guess valid result identifiers - which may be UUIDs or similarly non-guessable formats depending on implementation.

The overall risk is moderate-low in practice. CVSS 4.3 (Medium) reflects a network-accessible (AV:N), low-complexity (AC:L), low-privilege (PR:L), no-user-interaction (UI:N), unscoped (S:U) vulnerability with limited confidentiality impact (C:L) and no integrity or availability impact. The low-privilege requirement means an attacker must already hold a valid Kibana account, significantly narrowing the attack surface compared to unauthenticated IDOR flaws. The confidentiality impact is bounded to scheduled query result data, not credentials, session tokens, or full index contents. No EPSS data was supplied in the intelligence set; however, the PR:L constraint and narrow data scope suggest low exploitation probability in practice. No CISA KEV listing exists, and no public exploit code or proof-of-concept has been identified at time of analysis. The primary realistic risk is insider threat or account-compromised lateral movement across Spaces in multi-tenant Kibana deployments, not opportunistic internet-facing exploitation. Organizations running single-Space deployments or those without scheduled queries configured have no exposure.

An authenticated Kibana user with legitimate access to Space A discovers or enumerates the object identifier of a scheduled query result stored in Space B, to which they hold no authorization. By submitting a crafted API request using that identifier, the server returns the scheduled query result without enforcing Space membership checks, exposing potentially sensitive analytical data from the restricted Space. No exploit code is publicly known, but the attack requires only standard HTTP tooling and a valid session token.