Authorization Bypass Through User-Controlled Key in Elasticsearch Leading to Information Disclosure
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.
- Products
- elasticsearch
- Affected versions
- Not specified
- Fixed versions
- 8.19.23, 9.4.8, 9.5.5
- CVEs
- CVE-2026-103009
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 30 Oct 2026, 12:04 UTC · Revision 1
Source evidence
Authorization Bypass Through User-Controlled Key in Elasticsearch Leading to Information Disclosure
core-osv · Original sourcePublished 13 Oct 2026, 06:47 UTC
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.
osv:BIT-elasticsearch-2026-103009
elasticsearch
Fixed versions: 8.19.23, 9.4.8, 9.5.5
Complete source record
{
"id": "c3863dff778368978bdabd65f1e556ef2e9625d4b7286210de57eac4ed4467e2",
"url": "https://osv.dev/vulnerability/BIT-elasticsearch-2026-103009",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "Authorization Bypass Through User-Controlled Key in Elasticsearch Leading to Information Disclosure",
"summary": "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.",
"evidence": "osv:BIT-elasticsearch-2026-103009",
"products": [
{
"name": {
"value": "elasticsearch",
"evidence": "/affected/0/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "8.19.23",
"evidence": "/affected/0/ranges"
},
{
"value": "9.4.8",
"evidence": "/affected/0/ranges"
},
{
"value": "9.5.5",
"evidence": "/affected/0/ranges"
}
],
"affected_versions": []
}
],
"severity": "high",
"structured": {
"id": "BIT-elasticsearch-2026-103009",
"aliases": [
"BIT-elasticsearch-2026-103009",
"CVE-2026-103009"
],
"affected": [
{
"ranges": [
{
"type": "SEMVER",
"events": [
{
"introduced": "8.13.0"
},
{
"fixed": "8.19.23"
},
{
"introduced": "9.0.0"
},
{
"fixed": "9.4.8"
},
{
"introduced": "9.5.0"
},
{
"fixed": "9.5.5"
}
]
}
],
"package": {
"name": "elasticsearch",
"purl": "pkg:bitnami/elasticsearch",
"ecosystem": "Bitnami"
},
"severity": [
{
"type": "CVSS_V3",
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N"
}
],
"database_specific": {
"source": "https://github.com/bitnami/vulndb/tree/main/data/elasticsearch/BIT-elasticsearch-2026-103009.json"
}
}
],
"modified": "2026-10-14T11:00:06.203229209Z",
"provider": "osv",
"references": [
"https://discuss.elastic.co/t/elasticsearch-8-19-23-9-4-8-9-5-5-security-update-esa-2026-199/390874",
"https://nvd.nist.gov/vuln/detail/CVE-2026-103009"
],
"provider_metadata": {
"cpes": [
"cpe:2.3:a:elastic:elasticsearch:*:*:*:*:*:*:*:*",
"cpe:2.3:a:elastic:elasticsearch:*:*:*:*:*:maven:*:*"
],
"severity": "High"
}
},
"related_cves": [
{
"value": "CVE-2026-103009",
"evidence": "/aliases"
}
],
"security_relevant": true,
"severity_evidence": "/database_specific/severity"
},
"source_id": "core-osv",
"document_id": 316154,
"published_at": "2026-10-13T06:47:26.127+00:00"
}