CVE-2026-103009

Executive Summary

CVE-2026-103009 is an authorization bypass (CWE-639, Authorization Bypass Through User-Controlled Key) in Elasticsearch's handling of cross-cluster search requests under the Remote Cluster Security (RCS) 2.0 model. An attacker holding a cross-cluster API key authorized for one index can craft a request whose two independently-supplied identifying attributes refer to different indices, causing authorization to be validated against an accessible index while the operation is actually performed against a different, unauthorized index. The result is information disclosure — exposing document contents, field mappings, and other metadata — with a limited capability to modify retention-lease state on the unauthorized index.

Technical Analysis

The vulnerability is a classic identifier-mismatch authorization flaw (CWE-639). Elasticsearch's cross-cluster search (CCS) functionality, when operating under the Remote Cluster Security (RCS) 2.0 model, accepts requests that carry two distinct identifying attributes for the target shard. One attribute is used by the authorization check to determine whether the requester is permitted to perform the operation; the second, independently-supplied attribute determines which shard is actually accessed during execution.

Because the two attributes are validated and consumed independently, they can refer to different indices. This breaks the fundamental assumption that the resource authorized is the same resource operated upon. The authorization layer evaluates the request against an index the caller legitimately holds a cross-cluster API key for — for example, an index within their authorized scope — while the execution layer resolves the second attribute to an entirely different, unauthorized index.

The practical effect is a confused-deputy-style bypass: the caller's legitimate credentials are laundered through a request that grants access to data outside their authorization boundary. The precondition is a low-privileged but valid cross-cluster API key scoped to at least one index. No user interaction is required, and the attack is network-reachable, which is consistent with the CVSS vector (AV:N/AC:L/PR:L/UI:N) and produces high confidentiality impact (C:H) with limited integrity impact (I:L) reflecting the retention-lease state modification capability.

The flaw is specific to the cross-cluster search path under RCS 2.0. Single-cluster search and non-RCS remote cluster configurations are not described as affected by this mechanism. The description does not name specific API endpoints, parameter names, or code symbols; therefore, the precise request fields involved cannot be enumerated from the available intelligence. What is derivable is the vulnerability class and the divergence between the authorization-validated identifier and the execution-time identifier.

No public proof-of-concept, exploit code, or Nuclei template is available, and the vulnerability is not listed in CISA KEV as of this writing.

Exploitation Scenarios

No public PoC is available; the attack chain below is inferred from the vulnerability class (CWE-639 identifier mismatch in cross-cluster search) and the mechanisms described in the NVD entry. Specific function names, parameter names, and endpoints are not provided in the source data and are deliberately not invented here.

1. Reconnaissance / target identification. The attacker must already possess a valid cross-cluster API key authorized for at least one index reachable through the RCS 2.0 remote cluster security model. This is a low-privilege starting position (PR:L). The attacker enumerates or otherwise learns of a target index they are not authorized to access — for example, through index naming conventions, error messages, or knowledge of the deployment. Because the key is cross-cluster, the attacker's requests traverse the remote-cluster security path where the flawed check resides.

2. Triggering the flaw class. The attacker crafts a single cross-cluster search request that supplies two identifying attributes for the target shard that reference different indices: one attribute pointing at an index within their authorized scope, and a second attribute pointing at the unauthorized target index. The authorization evaluation validates only the first attribute — the authorized index — and therefore permits the request. The independent second attribute governs which shard is actually resolved and operated upon at execution time. This is the precise identifier-mismatch condition described as CWE-639: authorization is checked against a user-controllable key that does not match the resource ultimately accessed.

3. Payload / execution (vulnerability-class level). Carrying the crafted cross-cluster search request, the attacker submits the request using their legitimate key. No authentication bypass, credential theft, or malformed packet is required: the request is well-formed and authorized against the decoy index. The execution layer then operates against the unauthorized index specified by the second attribute. The attacker has not forged credentials; they have exploited the divergence between the two identifiers.

4. Post-exploitation impact. Successful exploitation yields information disclosure from the unauthorized index: document contents, field mappings, and other metadata become readable. In limited cases, the same request path allows modification of retention-lease state on the unauthorized index, a constrained integrity impact aligned with the I:L subscore. The attacker can repeat the technique against additional unauthorized indices as long as their key remains valid and the divergence condition can be constructed. There is no described remote-code-execution or privilege-escalation-to-admin component; the impact is bounded to confidentiality (high) and limited integrity modification within reachable cross-cluster data.

Impact Assessment

Successful exploitation primarily compromises confidentiality of data in indices the attacker is not authorized to read. The CVSS 3.1 base score of 7.1 (High) reflects network reachability (AV:N), low attack complexity (AC:L), low privileges required (PR:L), and no user interaction (UI:N). Scope is unchanged (S:U): the vulnerable component's authorization logic is subverted, but the impact stays within the Elasticsearch deployment's security authority. Confidentiality impact is High (C:H) — full read access to unauthorized index contents and metadata. Integrity impact is Low (I:L), limited to retention-lease state changes. Availability impact is None (A:N).

Blast radius: Any multi-cluster Elasticsearch deployment configured with Remote Cluster Security (RCS) 2.0 and cross-cluster search, where principals hold cross-cluster API keys scoped to a subset of indices, is exposed. Because the attacker's starting privilege is a legitimate low-privilege key, the flaw undermines the core tenet of tenant or team isolation in shared/federated search environments. Data commonly found in such indices — security telemetry, application logs, customer records, field mappings revealing schema and sensitive field names — may be disclosed. The limited integrity impact means defenders should also treat retention and lifecycle state on unauthorized indices as potentially tampered.

Business impact: Regulatory and contractual exposure from unauthorized access to data outside its intended scope; erosion of trust in cross-cluster access controls; possible lateral intelligence value to an attacker who can enumerate schemas and metadata. No CISA KEV listing and no known exploitation in the wild are reported, but absence of a patch (patch confidence 0/4) raises residual risk for exposed deployments.

Detection Guidance

Detection should focus on cross-cluster search requests that complete successfully but whose authorized index and accessed index diverge, and on anomalous read volume against indices rarely or never accessed by a given cross-cluster key. Because the description does not specify exact field or endpoint names, the rules below are necessarily generic to the vulnerability class (cross-cluster search under RCS 2.0) and must be tuned to the local schema, index names, and log field conventions.

Sigma Rule

title: Potential Elasticsearch Cross-Cluster Search Authorization Bypass (CVE-2026-103009)
id: 8b1c7f42-2026-4a10-9c3d-cve2026103009
status: experimental
description: Detects cross-cluster search activity that may indicate exploitation of an
  authorization bypass where an authorized index and a different, unauthorized index are
  referenced in the same request (CWE-639). Tune index fields to local schema.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-103009
author: valtersit.com Threat Intelligence
date: 2026/01/01
tags:
  - attack.t1190
  - cwe.639
logsource:
  product: elasticsearch
  service: audit
detection:
  selection_action:
    event.action:
      - 'indices:data/read/search'
      - 'indices:data/read/async_search/submit'
  selection_remote:
    elasticsearch.remote_cluster|exists: true
  selection_mismatch:
    - 'elasticsearch.request.indices': '*'
  condition: selection_action and selection_remote and selection_mismatch
  # Post-processing: alert where the value authorized by the API key scope differs from
  # the index ultimately accessed in the same request.
falsepositives:
  - Legitimate cross-cluster searches spanning multiple explicitly authorized indices
level: high

YARA Rule

rule CVE_2026_103009_ES_CCS_Authz_Bypass
{
    meta:
        description = "Detects cross-cluster search request artifacts referencing divergent index identifiers (CVE-2026-103009, CWE-639)"
        author = "valtersit.com Threat Intelligence"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-103009"
        date = "2026-01-01"
        severity = "high"

    strings:
        $ccs1 = "cross_cluster" ascii nocase wide
        $ccs2 = "ccs_minimize_roundtrips" ascii nocase
        $remote1 = "\"remote_cluster\"" ascii nocase wide
        $search1 = "_search" ascii
        $idx1 = "\"index\":" ascii nocase wide
        $idx2 = "\"indices\":" ascii nocase wide

    condition:
        uint32(0) != 0x504B0304 and
        (($ccs1 or $ccs2 or $remote1) and $search1 and ($idx1 or $idx2))
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-103009 Possible Elasticsearch Cross-Cluster Search Authorization Bypass"; \
flow:established,to_server; \
http.method; content:"POST"; \
http.uri; content:"_search"; nocase; \
http.request_body; content:"remote_cluster"; nocase; \
http.request_body; content:"index"; nocase; \
threshold:type both, track by_src, count 20, seconds 60; \
classtype:attempted-recon; \
sid:2026103009; rev:1; \
reference:url,nvd.nist.gov/vuln/detail/CVE-2026-103009;)

Elastic Detection

sequence by user.name with maxspan=5m
  [any where event.action == "indices:data/read/search"
       and elasticsearch.remote_cluster != null
       and elasticsearch.request.indices != null]
  [any where event.category == "database" and event.outcome == "success"
       and elasticsearch.request.indices != null]

Splunk SPL Query

index=elasticsearch_audit event.action IN ("indices:data/read/search","indices:data/read/async_search/submit")
| where isnotnull(remote_cluster) AND isnotnull(request_indices)
| stats count values(request_indices) as accessed_indices dc(request_indices) as index_count by user.name, remote_cluster, api_key.id
| where index_count > 1
| sort - count
| table user.name api_key.id remote_cluster accessed_indices index_count count

Wazuh OSSEC Rule

<group name="elasticsearch,cve-2026-103009,">
  <rule id="103009" level="12">
    <decoded_as>json</decoded_as>
    <field name="event.action">indices:data/read/search</field>
    <field name="remote_cluster">\.+</field>
    <description>CVE-2026-103009: Possible Elasticsearch cross-cluster search authorization bypass (CWE-639) by $(user.name)</description>
    <mitre>
      <id>T1190</id>
    </mitre>
    <group>authorization_bypass,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence is 0/4 (UNPATCHED) — no patch evidence exists from any tracked source, and no vendor fix or workaround is documented in the provided intelligence. Organizations must therefore rely on compensating controls until Elastic publishes an advisory and fix.

1. Immediate mitigations.

   • Minimize the attack surface: if cross-cluster search under RCS 2.0 is not operationally required, disable it or restrict remote cluster connectivity at the network layer (allow-list only trusted remote clusters, block external access to the transport/HTTP search paths).
   • Audit and reduce cross-cluster API keys: revoke or narrow the scope of keys that grant access to sensitive indices; enforce least privilege so that no key carries broader reach than necessary.
   • Segment sensitive indices into clusters/namespaces not reachable by low-privilege cross-cluster keys, since the bypass requires a key that is legitimately authorized for some index.
   • Increase monitoring of cross-cluster search logs; treat successful requests whose authorized and accessed indices diverge as high-severity alerts (see Detection Guidance).
   • Enable and retain Elasticsearch audit logging with sufficient request detail to reconstruct which index was authorized versus accessed.

2. Patch / upgrade steps.

   • Monitor Elastic's official security advisories and the NVD entry for CVE-2026-103009 for an assigned fixed version.
   • As soon as a fix is released, upgrade all Elasticsearch nodes in affected RCS 2.0 clusters; ensure rolling upgrades cover coordinating, master, and data roles consistently to avoid version skew in authorization behavior.
   • Re-validate cross-cluster API key scopes after patching to confirm the corrected authorization check behaves as expected.

3. Long-term hardening.

   • Adopt a "validate-before-resolve" design review for any component where an authorization decision and an execution decision consume different attributes — the class-level root cause here.
   • Enforce strict equality between the resource identifier used for authorization and the identifier used for execution across all cross-cluster and federated paths.
   • Implement continuous authorization testing (negative tests proving that a key scoped to index A cannot read index B through CCS).
   • Apply network micro-segmentation and mTLS for remote cluster links; monitor for anomalous schema/metadata enumeration indicative of post-exploitation reconnaissance.

References

• NVD — CVE-2026-103009: https://nvd.nist.gov/vuln/detail/CVE-2026-103009
• CWE-639 — Authorization Bypass Through User-Controlled Key: https://cwe.mitre.org/data/definitions/639.html
• Elastic Security Advisories (monitor for CVE-2026-103009 fix and affected version matrix): https://www.elastic.co/community/security
• Elasticsearch cross-cluster search and Remote Cluster Security (RCS) 2.0 documentation: https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-remote-clusters.html
• FIRST EPSS (no score published at time of writing): https://www.first.org/epss/

No threat actor campaigns, exploit-in-the-wild evidence, public PoC, or Nuclei template are associated with CVE-2026-103009 in the provided intelligence; CISA KEV listing is absent.