Kibana EUVD-2026-47578

Exploitation requires: (1) a valid Kibana account with access to the Reporting feature - anonymous or unauthenticated access is insufficient (PR:L per CVSS vector); (2) an administrator must have configured outbound request restrictions in Kibana - environments without any such policy configured have nothing to bypass but are also fully open to SSRF by design; (3) a target internal network destination reachable from the Kibana server process. Exploitation is limited by the requirement for Reporting feature access specifically (not just any authenticated session), and by the Low confidentiality impact ceiling - the attacker can cause outbound requests but cannot guarantee response data is returned in a useful form. Non-default configuration of outbound restrictions is a prerequisite; Kibana deployments with no restrictions configured are not 'bypassing' a control but are separately at risk of unrestricted SSRF through the same mechanism.

The provided CVSS 3.1 base score of 5.0 (AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N) accurately characterizes moderate real-world risk. The scope change (S:C) is the most significant signal: the reporting service can be weaponized to probe or interact with internal network segments not reachable directly by the attacker. Authentication is required (PR:L), and specifically access to the Reporting feature must be granted - this limits the exposed population to Kibana users with reporting permissions, not all authenticated users. Confidentiality impact is rated Low (C:L), consistent with SSRF-class issues where an attacker may retrieve partial responses from internal services but does not achieve full data exfiltration. No EPSS data was provided in the input; without it, exploitation probability cannot be quantified. No KEV listing and no POC are identified, suggesting opportunistic mass exploitation is not currently occurring. In environments where the Kibana Reporting feature is restricted to internal security analysts or operators and strict network segmentation already exists, real-world impact is further bounded. In flatter network architectures where Kibana has broad egress, this becomes a meaningful lateral reconnaissance vector.

An attacker with a low-privileged Kibana account that has been granted Reporting feature access submits a crafted report generation request containing a destination URL that abuses a gap in the administrator-configured blocklist - for example, using an alternate IP notation or URL-encoded form of a denied internal address. The Kibana reporting service, failing to normalize or fully validate the destination against all disallowed input variants, dispatches the HTTP request to the targeted internal host, potentially disclosing service banners, internal API responses, or metadata from cloud instance metadata endpoints (e.g., 169.254.169.254). No public POC has been identified, meaning exploitation currently requires independent discovery of the filter bypass technique.