Brief Summary: Kibana CVE-2026-33461 Fleet API Authorization Bypass Leaks Private Keys and Tokens

Introduction

A low privilege user with basic Fleet access in Kibana can silently extract private keys, enrollment tokens, and authentication secrets through an internal API endpoint that skips the authorization checks enforced everywhere else. For organizations running Elastic's observability and security stack, and that includes companies like Netflix, Uber, and Wikipedia, this means any authenticated user with minimal Fleet privileges could walk away with the credentials that govern agent enrollment and data pipeline integrity.

CVE-2026-33461 carries a CVSS score of 7.7 and is classified under CWE-863 (Incorrect Authorization). Elastic disclosed the issue on April 8, 2026, and released patched versions across three active release branches simultaneously.

Technical Information

Root Cause: Divergent Authorization Between Public and Internal APIs

The vulnerability originates from a fundamental inconsistency in how Kibana enforces access control across its Fleet API surface. The documented public endpoint GET /api/fleet/settings correctly requires the caller to hold fleet-settings-read privileges before returning any configuration data. This is the expected behavior and aligns with Kibana's role based access control model.

However, a separate internal API endpoint serves a similar function but without the same authorization gate. When this internal endpoint receives a request, it fetches the full Fleet configuration objects from the backend and returns them directly in the response body. There is no privilege check equivalent to what the public settings API enforces. The result is that any authenticated user who holds even limited Fleet privileges (for example, basic agent read access) can query this internal endpoint and receive the complete, unfiltered configuration payload.

What Gets Exposed

The unfiltered configuration objects returned by the vulnerable endpoint contain material that is operationally critical to Fleet management:

Private keys used in Fleet's internal communication and agent authentication
Authentication tokens including enrollment API keys generated via POST /api/fleet/enrollment_api_keys
Full configuration objects that would normally require fleet-settings-read or higher privileges to access

In the Elastic ecosystem, Fleet enrollment relies on API keys and tokens to authenticate Elastic Agents. The POST /api/fleet/enrollment_api_keys endpoint generates an api_key token used for enrolling agents, which normally requires fleet-agents-all privileges. Exposure of these tokens through the vulnerable internal endpoint means an attacker could hijack agent enrollment processes, manipulate downstream data pipelines, or pivot into other connected systems.

Attack Flow

Initial Access: An attacker authenticates to Kibana with a low privilege account that has been granted limited Fleet privileges. This is a common configuration in organizations where multiple teams interact with Fleet for agent monitoring.
Endpoint Discovery: The attacker identifies the internal Fleet API endpoint. Because this is an internal route, it may not appear in public API documentation, but it is reachable by any authenticated Kibana user with Fleet access.
Data Exfiltration: The attacker sends a request to the internal endpoint. The endpoint fetches the complete Fleet configuration objects, bypasses the authorization checks that the dedicated GET /api/fleet/settings API would enforce, and returns the full payload including private keys and authentication tokens.
Credential Abuse: With the extracted enrollment API keys and private keys, the attacker can enroll rogue Elastic Agents into the Fleet, intercept or manipulate telemetry data, or use the credentials to authenticate against other Elastic Stack components.

Default Configuration Amplifies Risk

The xpack.fleet.agents.enabled configuration parameter is set to true by default in Kibana. This means Fleet is active out of the box in standard deployments. Even environments configured for air gapped operations using the xpack.fleet.isAirGapped setting remain vulnerable, as the authorization bypass is independent of network topology. The attack requires only authenticated access to Kibana with minimal Fleet privileges.

Affected Systems and Versions

Elastic's advisory covers three release branches with the following patched versions:

Release Branch	Patched Version
8.x	8.19.14
9.2	9.2.8
9.3	9.3.3

All Kibana versions prior to these patched releases within their respective branches should be considered vulnerable. The advisory does not specify the exact earliest affected version in each branch. Any Kibana deployment with Fleet enabled (which is the default configuration via xpack.fleet.agents.enabled: true) is within the attack surface.

Vendor Security History

Elastic maintains an active security advisory program and has published multiple Kibana security updates in 2026. A prior coordinated disclosure, ESA-2026-12, addressed separate vulnerabilities in Kibana versions 8.19.12, 9.2.6, and 9.3.1. The Belgium Centre for Cybersecurity (CCB) has also issued advisories regarding multiple vulnerabilities in Elastic Kibana allowing arbitrary file reads and denial of service. Elastic's pattern of releasing synchronized patches across all active branches demonstrates a mature, multi branch release process, though the recurrence of authorization related issues in the Fleet component suggests this area of the codebase warrants continued scrutiny.

CVE Analysis

Experimental AI-Generated Content

Introduction

Technical Information