Kibana CVE-2026-82293

Requires a valid authenticated Kibana session (PR:L) - unauthenticated attackers cannot exploit this. The user must hold at least a basic Kibana role that grants login access, but explicitly should NOT hold machine_learning_user or machine_learning_admin privileges. The ML feature must be enabled in the Elastic Stack deployment (it is enabled by default in licensed tiers that include ML). Impact is strictly bounded to availability (resource consumption on the Elasticsearch cluster); no data exfiltration or configuration modification is possible via this flaw. Exploitation does not require user interaction from another party.

The CVSS 4.3 Medium rating is consistent with real-world risk here. The vector AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L confirms that exploitation requires a valid authenticated session (PR:L), reducing the exposed attack surface to users with at least a basic Kibana account. There is no confidentiality or integrity impact - the sole consequence is availability degradation (A:L) through unauthorized ML job execution consuming cluster resources. No public exploit code has been identified and this CVE does not appear in the CISA KEV catalog, making opportunistic exploitation unlikely. The absence of EPSS data prevents quantitative exploitation-probability comparison. Real-world priority is low to medium: organizations running multi-tenant Kibana deployments where untrusted authenticated users exist (e.g., SaaS platforms or shared analytics environments) face higher relative risk than those where all Kibana users are trusted employees. The 'Authentication Bypass' tag in the metadata is a mislabel - this is post-authentication authorization failure, not an authentication bypass.

An authenticated Kibana user assigned a read-only or viewer role crafts direct requests to Kibana's internal ML API endpoints - such as those for starting anomaly detection jobs - that should require machine_learning_admin privileges. Due to the incorrect authorization check, Kibana forwards these requests to Elasticsearch, which executes the ML jobs, consuming significant CPU and memory on the cluster. Repeated invocations could degrade Elasticsearch performance for legitimate users and operators.