Kibana CVE-2026-72669

Exploitation requires an authenticated Kibana session with at least generic read access to the target space - the CVSS vector PR:L confirms a low-privilege account is necessary, so unauthenticated access is not sufficient. The attacker and victim must be members of the same Kibana space; cross-space exploitation is not described. The Observability Onboarding feature must have been initiated by at least one other user in the space to produce discoverable flow state; if no onboarding flows exist, there is nothing to enumerate or tamper with. No special network position, elevated privileges, or non-default configuration is required beyond shared space membership. What limits exploitation: an attacker must first obtain valid Kibana credentials (PR:L), must share space access with a victim, and impact is confined to the Observability Onboarding subsystem - underlying Elasticsearch data, credentials, and other Kibana features are not in scope.

The vendor-assigned CVSS 7.6 (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:L) correctly captures the network-accessible, low-complexity attack requiring only a low-privilege authenticated session and no victim interaction. The high integrity impact (I:H) is the dominant signal - attackers can write arbitrary state into another user's onboarding flow without any ownership check. Confidentiality impact is bounded (C:L): only onboarding workflow metadata is exposed, not underlying Elasticsearch data or credentials. The availability impact (A:L) reflects the ability to cause persistent server errors in the victim's Observability Onboarding UI. Real-world risk is concentrated in multi-tenant or multi-team Kibana deployments where users of differing trust levels share a space; single-team or fully trusted-user environments face limited practical exposure. No EPSS score was provided, and CISA KEV status is not confirmed, meaning no evidence of active exploitation exists at time of analysis. The attack surface is further narrowed by the requirement that both attacker and victim occupy the same Kibana space and that the victim must have initiated an onboarding flow. This is a real priority for organizations running shared Kibana spaces but lower urgency for homogeneous trust environments.

An analyst-role user sharing a Kibana space with an administrator enumerates or guesses onboarding flow IDs - which may follow predictable patterns or be discoverable via the unguarded list route - then calls the onboarding state API to read the administrator's configuration progress, leaking integration setup details. The attacker subsequently writes malformed or misleading progress data into the flow; the next time the administrator opens the Observability Onboarding wizard, the corrupted state triggers a server error, blocking their setup and potentially masking a legitimate integration deployment.