Kibana CVE-2026-72629

The attacker must hold a valid, authenticated Kibana account (PR:L in the CVSS vector confirms this). The target environment must be running Kibana with the Elastic ML feature active (Stack ML, requiring at minimum a Platinum license or Elastic Cloud subscription tier that enables trained model deployments). Multiple Kibana Spaces must be in use - single-Space deployments are not meaningfully exposed because there is no cross-space boundary to bypass. The attacker must know or be able to guess/enumerate a valid model deployment ID or inference endpoint identifier belonging to the target Space; the CPE wildcard indicates no version-specific prerequisite. Exploitation is limited to users who already have network access to the Kibana API (no external unauthenticated path exists given PR:L). Users without a Kibana account and environments not using Kibana's ML model deployment feature are not at risk.

The CVSS base score of 7.1 (High) is driven primarily by C:H (full disclosure of cross-space model inference outputs) and A:L (ability to stop active deployments). The official vector records I:N, though the deployment-update operation - allowing arbitrary resource reallocation - arguably warrants I:L, yielding a score closer to 7.6. PR:L confirms a valid Kibana account is required, which substantially limits the attacker population to existing authenticated users rather than anonymous internet actors. AC:L indicates no special configuration or timing is needed once authentication is obtained. No EPSS data was provided; without it, base-rate exploitation probability cannot be quantified. The vulnerability is not listed in CISA KEV and no POC has been identified, indicating no confirmed active exploitation at time of analysis. Real-world priority is highest for multi-tenant Kibana deployments using the Elastic ML feature (Stack ML or Platinum/Enterprise subscription tiers), where cross-tenant confidentiality of model behavior is a business concern. Organizations running Kibana in single-Space or non-ML configurations face no material risk from this specific flaw.

An authenticated Kibana user assigned to Space A crafts API requests referencing trained ML model deployment IDs or inference endpoint paths belonging to Space B - IDs that the attacker has discovered through enumeration, leaked logs, or prior access. Because the authorization check does not validate Space membership of the resolved resource, the API returns inference outputs that reveal model behavior (e.g., classification logic, embedding patterns) from Space B. The same attacker can issue deployment-stop or resource-update requests against the Space B model, disrupting production ML inference for another team or tenant without ever appearing in Space B's audit logs. No public POC has been identified, so this scenario currently requires manual exploitation by a knowledgeable attacker.