Elasticsearch CVE-2026-72649 and the October ESA Batch: Who Can Reach It

On 1 September 2026 Elastic published ESA-2026-114 for CVE-2026-72649, a deserialization flaw in the Elasticsearch machine learning component. A specially crafted trained model artifact can make attacker-controlled logic execute on the node, and Elastic scores it 8.8. On 6 October a second batch followed: a privilege escalation, a cross-cluster authorization bypass, a data stream authorization bug and seven denial of service issues.

Almost every one of these needs an authenticated user. That is the useful part: who holds which privilege decides whether a given cluster is exposed.

What's affected

The September advisories:

• CVE-2026-72649 (ESA-2026-114, CVSS 8.8). Affects 8.0.0 through 8.19.19, 9.0.0 through 9.4.4, and 9.5.0. Fixed in 8.19.20, 9.4.5 and 9.5.1. The attacker needs an account that can create trained models, upload their definitions and start a deployment. Clusters with no machine learning capacity, or with ML disabled, are not affected.
• CVE-2026-78605 (ESA-2026-141, 5.9). HTTP request smuggling. The framing defect exists in every affected node with an HTTP/1.1 listener, but cross-user response disclosure also needs a proxy or load balancer that reuses backend connections across independent client sessions. Affects 8.18.0 through 8.19.19, 9.0.0 through 9.4.4, and 9.5.0. Same fixed versions as above.
• CVE-2026-78607 (ESA-2026-143, 5.4). In the custom inference service, a user with only inference execution privileges could redirect outbound inference traffic and expose admin-provisioned credentials. Only deployments using the custom inference service type with secret-backed configuration. Fixed in 8.19.19, 9.3.8, 9.4.4 and 9.5.1.

The 6 October advisories:

• CVE-2026-103007 (ESA-2026-197, 7.2). A user holding the delegated manage_roles privilege with a wildcard or regex index pattern can edit their own role to reach restricted indices, including internal security data, and climb to full cluster admin. Only affects roles scoped with patterns such as * or *kibana*. Fixed in 8.19.22, 9.4.7 and 9.5.4.
• CVE-2026-103009 (ESA-2026-199, 7.1). A cross-cluster API key holder authorized for one index can read another index on a cluster acting as the fulfilling side of cross-cluster search under the RCS 2.0 model. Not exploitable via the REST API. Fixed in 8.19.23, 9.4.8 and 9.5.5.
• CVE-2026-102407 (ESA-2026-188, 5.4). The Modify Data Streams API let a user modify a data stream they were not authorized for. Fixed in 8.19.19, 9.3.8 and 9.4.4. The 7.17 line (7.17.5 through 7.17.29) gets no fix.
• DoS group. CVE-2026-102404 (ES|QL memory growth, any low-privileged user who can run ES|QL), CVE-2026-102408 (ES|QL CHUNK regex backtracking, the built-in viewer role is enough), CVE-2026-102409 (text chunking recursion, 9.2.0 and later only), CVE-2026-102411 (manage_index_templates metadata exhausts heap), CVE-2026-103005 (connector description field, 8.12.0 and later), CVE-2026-103006 (deeply nested aggregations, read on one index) and CVE-2026-103008 (scripted runtime field geometry, read on one index). Three of these need manual intervention to bring the node back.

One target clears everything listed here: 8.19.23, 9.4.8 or 9.5.5. Elastic states there is no fix for 9.1.x, 9.2.x or 9.3.x for some of the DoS issues, so those lines need to move.

On Elastic Cloud Serverless, Elastic says the issues were remediated before disclosure, and CVE-2026-103007 and CVE-2026-103009 do not apply there. Elastic Cloud Hosted deployments still need a version upgrade.

How to check if you're exposed

ES=https://localhost:9200
AUTH="-u elastic:$ES_PASS"

curl -s $AUTH $ES | jq -r .version.number
curl -s $AUTH "$ES/_ml/info" | jq .limits
curl -s $AUTH "$ES/_cat/nodes?h=name,node.role"

curl -s $AUTH "$ES/_ml/trained_models?size=1000" \
  | jq -r '.trained_model_configs[] | [.model_id, .created_by, .create_time] | @tsv'

curl -s $AUTH "$ES/_security/role" \
  | jq -r 'to_entries[] | select(.value.cluster | index("manage_ml") or index("all")) | .key'

curl -s $AUTH "$ES/_security/role" \
  | jq 'to_entries[] | select(.value.global != null) | {role: .key, global: .value.global}'

curl -s $AUTH "$ES/_nodes/settings?filter_path=**.remote_cluster_server*,**.remote_cluster.port"

In order: the version, whether ML is enabled and which nodes carry the ML role, every trained model with its creator, roles granting manage_ml or all (CVE-2026-72649), roles with a global section where delegated role management lives (CVE-2026-103007), and whether the node serves RCS 2.0 cross-cluster traffic (CVE-2026-103009).

Creating a trained model through PUT _ml/trained_models requires the manage_ml cluster privilege, so the role query is the practical reachability test for CVE-2026-72649. Elastic's IOC guidance: a trained model your organization did not upload, or one sourced from an untrusted third party, is a sign of possible exploitation.

For CVE-2026-78605, look at what sits in front of port 9200. A reverse proxy with upstream keepalive, shared across users, is the configuration Elastic describes.

What to do now

1. Upgrade to 8.19.23, 9.4.8 or 9.5.5. Move off 9.1.x, 9.2.x and 9.3.x if you are on them.
2. If ML cannot be patched today, set xpack.ml.enabled: false on all nodes and restart, as ESA-2026-114 advises. On Cloud Hosted, remove ML capacity from the deployment.
3. Stop uploading third-party trained models to any cluster on an affected version.
4. Rewrite manage_roles delegations to use literal index names, and review audit logs for role edits by accounts holding that privilege.
5. If you do not need cross-cluster search under RCS 2.0, set remote_cluster_server.enabled: false on the fulfilling cluster (it defaults to false; port 9443 is the default listener when on).
6. Configure proxies not to reuse backend connections across client sessions. Elastic notes this blocks the disclosure but leaves the framing defect in place.

Why it matters

Model files are code. A trained model artifact passes through the same deserialization paths as any other untrusted input, and the privilege to upload one is often handed to data science teams as a routine grant. Treat manage_ml like a deploy key.

The DoS group points the same way. Several need only read access to one index, which is the permission most dashboards and service accounts already have. In a shared cluster, the least privileged user can take a node down.

Try it yourself

List every role in your cluster that holds manage_ml, manage_roles or manage_index_templates, and map each to a named owner. Any role you cannot explain is a candidate for removal before your next upgrade window. Then record each cluster's version in one place.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• ESA-2026-114, CVE-2026-72649
• ESA-2026-141, CVE-2026-78605
• ESA-2026-143, CVE-2026-78607
• ESA-2026-197, CVE-2026-103007
• ESA-2026-199, CVE-2026-103009
• ESA-2026-188, CVE-2026-102407
• ESA-2026-185, CVE-2026-102404
• ESA-2026-189, CVE-2026-102408
• ESA-2026-190, CVE-2026-102409
• ESA-2026-192, CVE-2026-102411
• ESA-2026-195, CVE-2026-103005
• ESA-2026-196, CVE-2026-103006
• ESA-2026-198, CVE-2026-103008
• NVD: CVE-2026-72649
• Elastic API docs: create a trained model (manage_ml)
• Elastic networking settings: remote_cluster_server.enabled