Kibana CVE-2026-33461

Requires authenticated access to Kibana as a user with Fleet privileges (any authenticated user with limited Fleet role). Attacker exploits internal API endpoint to bypass authorization checks and retrieve sensitive configuration data including private keys and tokens. No victim interaction needed. Affects Kibana instances with Fleet enabled.

The CVSS 7.7 score accurately reflects significant real-world risk due to multiple concerning factors. The attack vector is network-based (AV:N) with low complexity (AC:L) requiring only low-level privileges (PR:L) and no user interaction (UI:N), making exploitation straightforward for any authenticated user with Fleet access. The scope change (S:C) indicates the vulnerability transcends security boundaries, allowing Fleet-privileged users to access configuration contexts beyond their intended authorization domain. High confidentiality impact (C:H) is particularly concerning given the exposure of private keys and authentication tokens, which could enable further attacks including credential theft, lateral movement, or complete infrastructure compromise. However, several factors moderate immediate risk: no confirmed active exploitation exists (not present in CISA KEV), no publicly available exploit code has been identified, and exploitation requires valid authenticated credentials with at least Fleet-level privileges rather than unauthenticated remote access. The SSVC framework suggests moderate priority given the prerequisite authentication requirement and specific privilege context, though organizations using Kibana Fleet management should prioritize remediation given the sensitive nature of exposed data. The primary risk is to environments where multiple users have differentiated privilege levels within Kibana, particularly multi-tenant or managed service deployments where privilege separation is a critical security control.

An insider threat actor or compromised user account with legitimate Fleet privileges authenticates to a Kibana instance in a multi-tenant environment. Rather than using the standard settings UI which properly enforces role-based access controls, the attacker directly calls the vulnerable internal API endpoint that bypasses authorization checks. The API returns complete configuration objects including private keys used for inter-service authentication and API tokens for external integrations. The attacker extracts these credentials and uses them to authenticate to backend Elasticsearch clusters or connected services, escalating from limited Fleet management permissions to full infrastructure access. In a managed service provider scenario, this could allow a customer service account with only Fleet agent management rights to access configuration secrets belonging to other customers or the service provider's own infrastructure credentials.