Description

Incorrect Authorization (CWE-863) in Kibana can lead to privilege escalation via Input Data Manipulation (CAPEC-153). Elasticsearch cluster privilege declarations originating from integration packages were not validated before being used to mint credentials for enrolled Elastic Agents. A user holding Fleet management privileges could therefore cause every Elastic Agent on a targeted policy to receive a credential carrying arbitrarily elevated Elasticsearch cluster privileges, up to and including full cluster administration.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.1",
  "pubDate": "2026-09-03T19:17:28.550Z",
  "pubdate": "2026-09-03T19:17:28.550Z",
  "executiveSummary": "This vulnerability, classified under CWE-863 (Incorrect Authorization), exists within Kibana's integration package handling mechanism. It allows a user with Fleet management privileges to perform an escalation of privilege attack, aligning with CAPEC-153 (Input Data Manipulation).\nThe core issue involves the failure to validate Elasticsearch cluster privilege declarations within integration packages before utilizing these definitions to issue credentials for Elastic Agents.\nAn authenticated attacker possessing Fleet management capabilities can manipulate the integration policy configuration. By injecting arbitrary elevated cluster privileges into the policy, the attacker forces the system to mint credentials for enrolled Elastic Agents that possess permissions exceeding their intended scope, potentially reaching full cluster administrator status.\nThis flaw compromises the security boundary between managed agents and the underlying Elasticsearch cluster, enabling unauthorized access to sensitive data, cluster disruption, or persistence by leveraging the elevated credentials of the compromised agents. Exploitation requires existing authorization within the Fleet management interface.",
  "technicalDetails": "The vulnerability originates in the Kibana component responsible for processing and deploying integration packages to Elastic Agents. When an integration package is configured and assigned to an agent policy, the system must translate the requested permissions into valid Elasticsearch credentials.\nThe root cause is a lack of server-side input validation and sanitization regarding the privilege specifications defined within the integration package metadata. The system implicitly trusts the cluster privilege declarations provided during the policy creation or modification process.\nThe attack flow commences when an attacker, already possessing sufficient privileges to modify Fleet policies, crafts a malicious integration policy. The attacker defines specific Elasticsearch cluster privileges within this policy that are significantly broader than those required for the legitimate functionality of the integration.\nWhen Kibana processes this policy for deployment to target Elastic Agents, it proceeds to mint API keys or other credential artifacts based on the supplied, unvalidated declarations. The Elasticsearch security sub-system then issues these credentials to the enrolled agents.\nConsequently, the Elastic Agents—which operate in the context of the monitored infrastructure—now utilize credentials carrying the injected, excessive privileges. This effectively bypasses the Principle of Least Privilege, as the agent is no longer restricted to the minimum required access.\nThe impact is significant, as any malicious entity or process capable of interacting with or hijacking the communication flow of these agents can leverage the elevated credentials to perform unauthorized actions against the Elasticsearch cluster. This includes modifying index templates, accessing indices containing sensitive data, modifying cluster settings, or creating new administrative users to maintain persistence.\nBecause the trust is placed in the initial configuration input without verifying that the requested privileges align with the integration's documented requirements, the authorization enforcement point is effectively bypassed during the credential issuance phase."
}