Skip to main content
CVE Vulnerability Database

CVE-2020-7014: Elasticsearch Privilege Escalation Flaw

CVE-2020-7014 is a privilege escalation vulnerability in Elastic Elasticsearch affecting versions 6.7.0-6.8.7 and 7.0.0-7.6.1. Attackers with API key and token creation access can escalate privileges.

Updated:

CVE-2020-7014 Overview

CVE-2020-7014 is a privilege escalation vulnerability in Elastic Elasticsearch resulting from an incomplete fix for CVE-2020-7009. The flaw affects Elasticsearch versions 6.7.0 through 6.8.7 and 7.0.0 through 7.6.1. An authenticated attacker who can create both an API key and an authentication token can chain these operations to generate an authentication token with elevated privileges. The weakness maps to CWE-266 (Incorrect Privilege Assignment) and CWE-269 (Improper Privilege Management).

Critical Impact

An authenticated user with API key and token creation permissions can escalate to higher-privileged operations, compromising confidentiality, integrity, and availability of the Elasticsearch cluster.

Affected Products

  • Elastic Elasticsearch 6.7.0 through 6.8.7
  • Elastic Elasticsearch 7.0.0 through 7.6.1
  • NetApp products bundling affected Elasticsearch versions (see NetApp Advisory NTAP-20200619-0003)

Discovery Timeline

  • 2020-06-03 - CVE-2020-7014 published to NVD
  • 2024-11-21 - Last updated in NVD database

Technical Details for CVE-2020-7014

Vulnerability Analysis

The vulnerability resides in how Elasticsearch's security subsystem handles the interaction between API keys and authentication tokens. The original patch for CVE-2020-7009 failed to fully constrain privilege inheritance when tokens are generated through chained authentication primitives. An attacker who already possesses credentials capable of creating API keys and authentication tokens can perform a sequence of operations that produces a token bound to elevated privileges rather than the privileges of the originating user.

The attack requires low-complexity network access and low privileges, but no user interaction. Successful exploitation yields full read, write, and availability impact on cluster data and operations. Because Elasticsearch frequently stores logs, telemetry, and business-critical search indexes, escalated access often translates to broad data exposure.

Root Cause

The root cause is improper privilege management ([CWE-269]) in the token generation logic. When an API key was used as part of the authentication token creation workflow, the resulting token did not correctly inherit the restricted privilege set of the originating API key. Instead, the token could be associated with privileges beyond what the attacker was authorized to hold, an incorrect privilege assignment ([CWE-266]).

Attack Vector

Exploitation requires network access to the Elasticsearch REST API and an account with permissions to call the _security/api_key and _security/oauth2/token endpoints. The attacker first creates an API key, then uses that key in a chained call to obtain an authentication token. Due to the incomplete fix, the resulting token is issued with elevated privileges. The attacker can then operate against cluster APIs using the escalated token, including reading indices, modifying mappings, or disrupting cluster state.

No public proof-of-concept is listed in CISA KEV or ExploitDB, and the EPSS data indicates the vulnerability is not currently observed in active mass exploitation campaigns. See the Elastic Security Resources page for the vendor advisory and technical details.

Detection Methods for CVE-2020-7014

Indicators of Compromise

  • Unexpected API key creation events in Elasticsearch audit logs originating from low-privilege user accounts.
  • Authentication token generation requests immediately following API key creation by the same principal.
  • Successful operations on privileged endpoints (cluster state changes, role modifications, index template edits) by accounts that historically lacked those permissions.
  • New tokens whose associated privileges exceed those of the issuing user or API key.

Detection Strategies

  • Enable Elasticsearch audit logging and forward events to a centralized SIEM for correlation of create_apikey and create_token actions by the same user within short time windows.
  • Baseline normal API key and token issuance behavior per user, then alert on deviations such as unusual issuance frequency or off-hours activity.
  • Compare granted token privileges against the issuing user's role assignments and flag mismatches.

Monitoring Recommendations

  • Monitor the _security/api_key and _security/oauth2/token endpoints for anomalous call patterns.
  • Track changes to role mappings, cluster settings, and index permissions performed via token-based authentication.
  • Alert on authentication tokens used to access indices outside the user's documented scope.

How to Mitigate CVE-2020-7014

Immediate Actions Required

  • Upgrade Elasticsearch to version 6.8.8 or later in the 6.x branch, or 7.6.2 or later in the 7.x branch.
  • Audit all existing API keys and authentication tokens, invalidating any that cannot be tied to legitimate workflows.
  • Review role assignments to ensure only required users hold manage_api_key and token creation privileges.
  • Rotate credentials and tokens for accounts that may have been used to exploit the flaw.

Patch Information

Elastic addressed CVE-2020-7014 in Elasticsearch 6.8.8 and 7.6.2. Refer to the Elastic Security Resources page for the official advisory. Organizations running Elasticsearch as part of NetApp products should consult NetApp Security Advisory NTAP-20200619-0003 for vendor-specific update guidance.

Workarounds

  • Restrict the manage_api_key cluster privilege to a minimal set of trusted administrative accounts.
  • Disable API key generation for end users who do not require it until patches can be deployed.
  • Place Elasticsearch behind a reverse proxy that enforces additional authentication and rate limiting on _security endpoints.
  • Enable and review audit logging for all security-related API calls to detect exploitation attempts.
bash
# Example: restrict api_key management via role definition
PUT /_security/role/restricted_apikey_role
{
  "cluster": ["monitor"],
  "indices": [
    {
      "names": ["app-logs-*"],
      "privileges": ["read"]
    }
  ]
}
# Ensure only designated admins hold the built-in 'manage_api_key' privilege

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.