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 (Netflix, Uber, and Wikipedia among them), 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 has 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 for three active release branches at the same time.

Technical Information

Root Cause: Divergent Authorization Between Public and Internal APIs

The vulnerability comes from an 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 it returns any configuration data. That is the expected behavior, and it matches Kibana's role-based access control model.

A separate internal API endpoint does a similar job without that authorization gate. When it receives a request, it fetches the full Fleet configuration objects from the backend and returns them directly in the response body. It runs no privilege check equivalent to the one the public settings API enforces. Any authenticated user with 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 that the vulnerable endpoint returns contain material that Fleet management depends on to operate:

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

Fleet enrollment relies on API keys and tokens to authenticate Elastic Agents. The POST /api/fleet/enrollment_api_keys endpoint, which normally requires fleet-agents-all privileges, generates an api_key token used to enroll agents. An attacker who obtains these tokens through the vulnerable internal endpoint could hijack agent enrollment, 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 limited Fleet privileges. Organizations where several teams use Fleet for agent monitoring commonly configure accounts this way.
Endpoint Discovery: The attacker finds the internal Fleet API endpoint. As an internal route, it may not appear in the public API documentation, but any authenticated Kibana user with Fleet access can reach it.
Data Exfiltration: The attacker sends a request to the internal endpoint. The endpoint fetches the complete Fleet configuration objects, skips the authorization checks that the dedicated GET /api/fleet/settings API would enforce, and returns the full payload, private keys and authentication tokens included.
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

Kibana sets the xpack.fleet.agents.enabled configuration parameter to true by default, so Fleet is active out of the box in standard deployments. Environments configured for air-gapped operation with the xpack.fleet.isAirGapped setting are still vulnerable, because the authorization bypass does not depend on network topology. The attack needs only authenticated access to Kibana with minimal Fleet privileges.

Affected Systems and Versions

Elastic's advisory lists patched versions for three release branches:

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

Treat every Kibana version before the patched release in its branch as vulnerable. The advisory does not give the earliest affected version in each branch. Any Kibana deployment with Fleet enabled (the default, via xpack.fleet.agents.enabled: true) is within the attack surface.

Vendor Security History

Elastic runs an active security advisory program and has published several Kibana security updates in 2026. An earlier coordinated disclosure, ESA-2026-12, fixed 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 about multiple vulnerabilities in Elastic Kibana that allow arbitrary file reads and denial of service. Elastic releases synchronized patches across all active branches, which shows a mature, multi-branch release process. Authorization issues keep recurring in the Fleet component, though, and that suggests this part of the codebase needs continued scrutiny.

CVE Analysis

Experimental AI-Generated Content

Introduction

Technical Information