CVE-2026-33461: 
Kibana vulnerability analysis and mitigation

CVE-2026-33461 is an Incorrect Authorization vulnerability (CWE-863) in Elastic Kibana that enables information disclosure via Privilege Abuse (CAPEC-122). A user with limited Fleet privileges can exploit an internal API endpoint to retrieve sensitive configuration data — including private keys and authentication tokens — that should only be accessible to users with higher-level settings privileges. The vulnerability affects Kibana versions 8.0.0 through 8.19.13, 9.0.0 through 9.2.7, and 9.3.0 through 9.3.2. It was published on April 8, 2026, with patches released the same day. The CVSS v3.1 base score is 6.5 (Medium) per NVD, though ENISA and GitHub Advisory Database rate it 7.7 (High) using a scope-changed vector (GitHub Advisory, Elastic Advisory).

The root cause is an Incorrect Authorization flaw (CWE-863) in an internal Kibana API endpoint used by the Fleet feature. The endpoint composes its response by fetching full configuration objects from the backend and returning them directly to the caller, without applying the authorization checks that the dedicated settings APIs enforce. This means a low-privileged user with any Fleet access can send a network request to this internal endpoint and receive sensitive configuration data — such as private keys and authentication tokens — that are normally gated behind higher-privilege settings roles. No user interaction is required, and the attack complexity is low, making exploitation straightforward for any authenticated Fleet user (GitHub Advisory, Elastic Advisory).

Successful exploitation allows a low-privileged Kibana user with Fleet access to retrieve sensitive configuration data including private keys and authentication tokens that should be restricted to administrative users. This information disclosure could enable an attacker to impersonate administrative users, gain unauthorized access to protected resources, or pivot to other systems integrated with the Kibana/Elasticsearch environment. There is no integrity or availability impact; the vulnerability is purely a confidentiality breach, but the sensitivity of the exposed credentials makes it a significant risk for lateral movement and privilege escalation (GitHub Advisory, Elastic Advisory).

As of the time of reporting, there is no public proof-of-concept exploit and no evidence of in-the-wild exploitation (GitHub Advisory). The EPSS score is approximately 0.055% (17th percentile), indicating a low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires a valid Kibana account with at least limited Fleet privileges, which limits the attacker pool but does not require administrative access.

1. Reconnaissance: Identify a Kibana instance running a vulnerable version (8.0.0–8.19.13, 9.0.0–9.2.7, or 9.3.0–9.3.2) accessible over the network.
2. Obtain Fleet credentials: Acquire or use an existing Kibana user account that has limited Fleet privileges (e.g., a standard analyst or operator account with Fleet read access).
3. Identify the internal API endpoint: Locate the internal Kibana Fleet API endpoint that returns full configuration objects. This endpoint is not intended for direct use by low-privileged users but is accessible without proper authorization enforcement.
4. Send crafted API request: Authenticate to Kibana and issue an HTTP GET request to the vulnerable internal Fleet API endpoint using the low-privileged credentials.
5. Retrieve sensitive data: Parse the API response, which returns full configuration objects including private keys and authentication tokens that should be restricted to higher-privileged settings users.
6. Leverage exposed credentials: Use the retrieved private keys or authentication tokens to escalate privileges, authenticate to other services, or perform further lateral movement within the environment (GitHub Advisory, Elastic Advisory).

• Network: Unusual or repeated HTTP GET requests from low-privileged Fleet user accounts to internal Kibana Fleet API endpoints that are not part of normal Fleet operational workflows.
• Logs: Kibana access logs showing Fleet-privileged users accessing internal configuration API endpoints that return full configuration objects; look for API calls that return large configuration payloads to accounts that do not have settings-level privileges.
• Logs: Authentication events showing the use of credentials (tokens or keys) retrieved from Kibana configuration in unexpected contexts or from unexpected source IPs shortly after Kibana API access.
• Behavioral: Accounts with Fleet-only roles accessing settings or configuration endpoints outside their normal access pattern, particularly if followed by new authentication activity from those accounts or associated IPs (Elastic Advisory).

Elastic has released patched versions addressing this vulnerability: 8.19.14 for the 8.x branch, 9.2.8 for the 9.2.x branch, and 9.3.3 for the 9.3.x branch. Organizations should upgrade to one of these versions as the primary remediation. As interim measures, administrators should review Kibana access logs to identify any Fleet-privileged users who may have accessed internal API endpoints, and audit and rotate any sensitive credentials (private keys, authentication tokens) that could have been exposed. Additionally, consider implementing network-level access controls to restrict access to Kibana's internal APIs where feasible (Elastic Advisory, GitHub Advisory).

The vulnerability received standard automated coverage across vulnerability tracking platforms (NVD, VulnDB, CVE.org) shortly after disclosure on April 8, 2026. Social media mentions were observed on Bluesky and Mastodon, primarily from automated CVE notification accounts. No notable independent researcher commentary or significant media coverage has been identified beyond routine vulnerability database entries (Elastic Advisory).