Kibana EUVD-2026-33032

Exploitation requires an authenticated Kibana session holding the connector management privilege (the Actions and Connectors feature, typically granted via the Management → Stack Management privilege set or kibana_admin role), and the target Kibana deployment must have the operator-configured connection allowlist (xpack.actions.allowedHosts or customHostSettings) in use - the bug specifically defeats that control, so deployments that never enforced an allowlist gain no additional protection but also have nothing being bypassed. The attack is specifically performed by configuring a Webhook connector with a crafted target URL pointing to a destination the allowlist intended to block. Exploitation is limited by the PR:L requirement (no anonymous access), by the need for the operator to have actually configured restrictive egress controls in the first place for the bypass to be meaningful, and by the value of network-reachable internal destinations from the Kibana host.

The CVSS 7.7 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N) accurately reflects the realistic risk profile: network-reachable, low complexity, requires low-privileged authentication, no user interaction, and notably a Scope=Changed with High confidentiality impact - meaning the attacker can pivot to read data outside Kibana's own trust boundary (the classic SSRF pivot). The PR:L requirement is meaningful: an attacker must already hold an account with connector management privileges, which is typically restricted to administrators or trusted automation roles, sharply limiting opportunistic exploitation. There is no EPSS score, KEV listing, or public POC referenced in the available data, so this is best characterized as an insider-or-post-compromise privilege-bypass risk rather than a mass-exploitation candidate, but the Scope:Changed/C:H combination makes it high priority where Kibana is deployed alongside sensitive internal services (cloud metadata, Elasticsearch admin endpoints, vault APIs).

An attacker who has obtained or been granted a Kibana account with connector management privileges - for example, a low-tier SOC analyst role over-provisioned with kibana_admin or a leaked CI service account - logs in to Kibana, creates a Webhook connector whose URL targets an internal-only address such as a cloud metadata endpoint or an Elasticsearch admin API, and triggers the connector via a test action or rule execution. Kibana's server process issues the outbound request despite the operator-configured allowlist, returning response data or side effects to the attacker and enabling credential theft, internal reconnaissance, or pivoting onto the internal network.