Vulnerability record · CVE-2018-11770 · published 13 August 2018
CVE-2018-11770: Apache Spark standalone master REST API lacks authentication
Apache · Spark
From version 1.3.0 onward, the Apache Spark standalone master exposes a REST API for job submission that does not use the shared secret (spark.authenticate.secret) or any other authentication mechanism, and this gap is not adequately documented. An unauthenticated user can submit a driver program through that API, which matters because job submission is a privileged operation on a shared cluster.
Description
From version 1.3.0 onward, Apache Spark's standalone master exposes a REST API for job submission, in addition to the submission mechanism used by spark-submit. In standalone, the config property 'spark.authenticate.secret' establishes a shared secret for authenticating requests to submit jobs via spark-submit. However, the REST API does not use this or any other authentication mechanism, and this is not adequately documented. In this case, a user would be able to run a driver program without authenticating, but not launch executors, using the REST API. This REST API is also used by Mesos, when set up to run in cluster mode (i.e., when also running MesosClusterDispatcher), for job submission. Future versions of Spark will improve documentation on these points, and prohibit setting 'spark.authenticate.secret' when running the REST APIs, to make this clear. Future versions will also disable the REST API by default in the standalone master by changing the default value of 'spark.master.rest.enabled' to 'false'.
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N
Automated analysis
medium priorityThe flaw allows unauthenticated driver submission but not executor launch, and CVSS rates it medium (4.2) despite a high EPSS score and an exploit-tagged advisory.
What it is
From version 1.3.0 onward, the Apache Spark standalone master exposes a REST API for job submission that does not use the shared secret (spark.authenticate.secret) or any other authentication mechanism, and this gap is not adequately documented. An unauthenticated user can submit a driver program through that API, which matters because job submission is a privileged operation on a shared cluster.
Impact
An attacker can run a driver program on the cluster without authenticating, consuming cluster resources and executing code under the cluster's context. The description states they cannot launch executors via this path, so the gain is limited to driver submission rather than full executor control.
Attack surface
Reached over the network via the Spark standalone master REST API (and the same API when used by Mesos in cluster mode with MesosClusterDispatcher). No authentication is required; the CVSS vector indicates network access with low privileges and no user interaction.
Exploitation
Not listed in CISA KEV and no ransomware usage is documented; EPSS is high (0.6583, 99.2nd percentile), and the vendor advisory reference is tagged Exploit, indicating public exploit information exists.
What to do
- Upgrade to a Spark release that disables the standalone master REST API by default (spark.master.rest.enabled=false) and prohibits setting spark.authenticate.secret when REST APIs are enabled.
- If upgrading is not immediate, set spark.master.rest.enabled to false on standalone masters and Mesos cluster dispatchers.
- Restrict network access to the Spark master REST port to trusted hosts only.
- Do not rely on spark.authenticate.secret to protect the REST API; it does not apply to it.
- Review cluster job submission logs for unexpected driver submissions.
Detection
- Monitor Spark master REST API endpoints for job submission requests from unexpected source hosts.
- Alert on driver submissions that do not correlate with known spark-submit clients or authorized users.
- Audit whether spark.master.rest.enabled is true on standalone masters and Mesos cluster dispatchers.
- Review Spark master and dispatcher logs for anomalous driver creation events.
This assessment is produced automatically and is not human-reviewed. Verify against the vendor advisory before acting on it.
Affected products
1 vulnerable configurations from NVD's CPE data, grouped by vendor and product.
References
| Link | Tags |
|---|---|
| http://www.securityfocus.com/bid/105097 | Broken LinkThird Party AdvisoryVDB Entry |
| https://lists.apache.org/thread.html/bd8e51314041451a2acd720e9223fc1c15a263ccacb396a75b1fc485%40%3Cdev.spark.apache.org% | Mailing ListThird Party Advisory |
| https://spark.apache.org/security.html#CVE-2018-11770 | ExploitMitigationVendor Advisory |
| http://www.securityfocus.com/bid/105097 | Broken LinkThird Party AdvisoryVDB Entry |
| https://lists.apache.org/thread.html/bd8e51314041451a2acd720e9223fc1c15a263ccacb396a75b1fc485%40%3Cdev.spark.apache.org% | Mailing ListThird Party Advisory |
| https://spark.apache.org/security.html#CVE-2018-11770 | ExploitMitigationVendor Advisory |
Track CVE-2018-11770 inside VULONE
Watch it alongside the ransomware crews, C2 infrastructure and forum chatter that reference it, query it through the API and pull it into your SIEM over TAXII.
Related vulnerabilities
Same products first, then exploited flaws of the same weakness class.
Source: NIST National Vulnerability Database (record CVE-2018-11770), CISA KEV, FIRST EPSS (scores of 2026-09-26). This page is refreshed as NVD updates the record.
