CVE-2026-78609: Elastic Cloud on Kubernetes Auth Bypass

CVE-2026-78609 is an authorization bypass flaw in Elastic Cloud on Kubernetes that allows attackers with limited namespace permissions to inject malicious certificates into trust bundles. This article covers technical details, affected versions, security impact, and recommended mitigation strategies.

CVE-2026-78609 Overview

CVE-2026-78609 is an Incorrect Authorization flaw [CWE-863] in Elastic Cloud on Kubernetes (ECK). The operator permits an actor with limited Kubernetes permissions scoped to a single namespace to influence resources reconciled into a different namespace. Specifically, attacker-controlled certificate material can be injected into the Elasticsearch client trust bundle that ECK manages, enabling Metadata Spoofing (CAPEC-690). The result is unauthorized modification of data trusted by Elasticsearch clients. Elastic addressed the issue in ECK 3.5.0 through security update ESA-2026-145.

Critical Impact
A namespace-scoped Kubernetes user can cause ECK to trust attacker-supplied certificates, enabling interception or spoofing of Elasticsearch client traffic across tenant boundaries.

Affected Products

Elastic Cloud on Kubernetes (ECK) operator versions prior to 3.5.0
Elasticsearch clusters managed by vulnerable ECK operators
Multi-tenant Kubernetes environments using ECK for Elastic Stack orchestration

Discovery Timeline

2026-09-02 - CVE-2026-78609 published to NVD
2026-09-02 - Last updated in NVD database
ESA-2026-145 - Elastic publishes security advisory covering ECK 3.5.0 fix

Technical Details for CVE-2026-78609

Vulnerability Analysis

ECK runs as a Kubernetes operator that reconciles Elastic Stack custom resources and manages supporting Secrets across namespaces. The trust bundle used by Elasticsearch clients is assembled by the operator from referenced resources. The vulnerability arises because ECK does not adequately validate whether the caller referencing certificate material is authorized to affect the destination namespace where the trust bundle lives.

An actor holding create or update permissions on relevant resources in a single namespace can craft input that ECK later merges into the client trust bundle managed in a separate namespace. Downstream Elasticsearch clients then trust the attacker-supplied certificate authority. This breaks the tenant isolation model that multi-namespace Kubernetes deployments rely on.

Root Cause

The root cause is missing cross-namespace authorization checks in the reconciliation logic. ECK treats certificate references as trusted based on the operator's own service account privileges rather than validating the requester's permissions on the target namespace. This is a classic [CWE-863] Incorrect Authorization pattern applied to a controller pattern.

Attack Vector

Exploitation requires low-privilege authenticated access to a Kubernetes namespace managed by ECK. The attacker submits a resource that causes ECK to include their certificate material in the Elasticsearch client trust bundle in another namespace. Once accepted, the attacker can present TLS certificates signed by their controlled authority and impersonate legitimate Elasticsearch endpoints. Clients configured to trust the ECK-managed bundle will accept spoofed metadata and route traffic to attacker-controlled services.

No verified public exploit code is available. See the Elastic Security Update ESA-2026-145 for vendor-supplied technical details.

Detection Methods for CVE-2026-78609

Indicators of Compromise

Unexpected certificate authorities or additional CA entries appearing in ECK-managed trust bundle Secrets
ECK operator reconciliation events referencing resources in namespaces outside the intended tenant boundary
Elasticsearch client connections completing successfully against endpoints presenting previously unknown issuer chains

Detection Strategies

Audit Kubernetes API server logs for create and update operations on ECK custom resources by low-privileged service accounts
Compare current ECK-managed Secret contents against a known-good baseline of trusted CA material
Monitor for TLS handshakes in Elasticsearch traffic where the presented certificate chain does not match the organization's issuing PKI

Monitoring Recommendations

Enable Kubernetes audit logging at the RequestResponse level for ECK-managed namespaces and forward events to a centralized analytics platform
Alert on modifications to Secrets in namespaces hosting Elasticsearch trust bundles
Track ECK operator logs for reconciliation errors or cross-namespace reference warnings that may indicate probing activity

How to Mitigate CVE-2026-78609

Immediate Actions Required

Upgrade the ECK operator to version 3.5.0 or later as directed by ESA-2026-145
Review Kubernetes RBAC bindings and remove unnecessary write permissions on ECK custom resources in shared clusters
Rotate any Elasticsearch CA material and client certificates that may have been influenced during the exposure window

Patch Information

Elastic released the fix in Elastic Cloud on Kubernetes 3.5.0. Full remediation details are documented in the Elastic Security Update ESA-2026-145. Operators should apply the upgrade following Elastic's documented ECK upgrade procedure and verify the new operator image digest in cluster deployments.

Workarounds

Restrict namespace-scoped user permissions on custom resources that ECK consumes for certificate references
Isolate ECK-managed Elasticsearch instances into dedicated clusters when strict multi-tenant boundaries are required
Enforce Kubernetes admission policies that reject cross-namespace references in ECK resources until the operator is patched

bash

# Verify installed ECK operator version and plan upgrade
kubectl -n elastic-system get statefulset elastic-operator \
  -o jsonpath='{.spec.template.spec.containers[0].image}'

# Review RBAC bindings that grant write access to Elastic CRDs
kubectl get rolebindings,clusterrolebindings -A -o json | \
  jq '.items[] | select(.roleRef.name | test("elastic"))'