CVE-2026-103009
Elasticsearch: authorisation bypass can lead to information disclosure
- Risk score
- 45/100
- CVSS
- 7.1 v3.1
- Exploit chance (30 days)
- 0.2%
- Published
- 6 Oct 2026
Open in the live forecast Today's forecast
What to know
- What it is
- Authorization Bypass Through User-Controlled Key (CWE-639) in Elasticsearch can lead to Information Disclosure via a specially crafted cross-cluster search request that references an unauthorized shard identifier. Elasticsearch contains an authorization bypass weakness in its handling of cross-cluster search requests …
- Affected
- Elasticsearch
- Fix
- Apply the vendor's security update; see the linked advisory.
- Exploitation
- No known exploitation
Story map
At a glance
Elasticsearch: Yellow, plan it in. Incorrect Authorization (CWE-863) in Elasticsearch can lead to Privilege Escalation via a delegated administrative privilege whose scope is not fully enforced during authorization checks. Elasticsearch contains an incorrect authorization weakness in a configurable, non-default privilege that lets an administrator dele…
The flaws
- CVE-2026-103009: Authorisation bypass can lead to information disclosure (CVSS 7.1 · EPSS 0%)
- CVE-2026-103007: Incorrect authorisation can lead to privilege escalation (CVSS 7.2 · EPSS 0%)
- CVE-2026-82294: Denial of service (CVSS 6.5 · EPSS 0%)
- CVE-2026-82300: Denial of service (CVSS 6.5 · EPSS 0%)
The fix
Fix: Apply the vendor's security update; see the linked advisory.
Who is exposed: Elasticsearch
Where it stands
- No known exploitation
Connects to
- Same weakness: Authorisation bypass (CWE-639). 246 other warnings in 30 days
- Same product: Earlier Elasticsearch warnings. 13 in the last 90 days
Why it is Yellow
- CVSS 7.1 high
References
Original description
Authorization Bypass Through User-Controlled Key (CWE-639) in Elasticsearch can lead to Information Disclosure via a specially crafted cross-cluster search request that references an unauthorized shard identifier. Elasticsearch contains an authorization bypass weakness in its handling of cross-cluster search requests made through the Remote Cluster Security (RCS) 2.0 model. An authorization check validates a request against one identifying attribute of the target shard, while a separate, independently-supplied identifying attribute in the same request determines which shard is actually accessed. A holder of a cross-cluster API key authorized for one index can craft a request whose two identifying attributes refer to different indices, causing the request to be authorized against an index they can access while actually operating against a different, unauthorized index. This can expose that index's document contents, field mappings, and other metadata, and in limited cases allows modification of retention-lease state on the unauthorized index.
Last activity 6 Oct 2026. Patch Forecast updates every hour.