Overview 21 matches · 0 protected · 2 exploited · 0 CISA KEV · 2 public PoC · 2 EPSS ≥ 0.5
Protected by Waratek
0
0.0%
Rule in development
0
0.0%
Mitigation candidate
2
9.5%
No exploit published
19
90.5%
blocked by ARMR today
0
0.0%
partly blocked
0
0.0%
not blocked
21
100.0%
not established
0
0.0%
unrecorded
0
0.0%
Exploited
2
9.5%
Working exploit published
0
0.0%
Proof of concept only
0
0.0%
Forecast only
1
4.8%
No public exploit
18
85.7%
split by
peak 4 / year
20171
No exploit published1
Medium1
not blocked1
No public exploit1
20183
Mitigation candidate1
No exploit published2
High1
Medium2
not blocked3
Exploited1
No public exploit2
20194
No exploit published4
High2
Medium2
not blocked4
No public exploit4
20203
Mitigation candidate1
No exploit published2
Critical2
Medium1
not blocked3
Exploited1
No public exploit2
20211
No exploit published1
Medium1
not blocked1
Forecast only1
20223
No exploit published3
High1
Medium2
not blocked3
No public exploit3
20232
No exploit published2
Critical1
Medium1
not blocked2
No public exploit2
20242
No exploit published2
High1
Medium1
not blocked2
No public exploit2
20251
No exploit published1
Medium1
not blocked1
No public exploit1
20261
No exploit published1
Medium1
not blocked1
No public exploit1
2017201820192020202120222023202420252026
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2026-32773 | Medium | 2026-09-02 | No exploit published | No public exploit | There is a lack of XSS escaping in the Spark History Server prior to 3.5.8 which allows a malicious Spark job to generate arbitrary unescaped frontend code which could lead to a minimal privilege escalation in browser. Users are encouraged to upgrade to Spark 3.5.8 or later. This CVE is marked as "low" since the path to exploit requires both relatively high permissions (ability to launch a Spark job) and requires tricking a user with higher permissions to log in and visit the Spark history web page. Users are encouraged to upgrade their Spark history servers to Spark 3.5.8 or later. |
| CVE-2025-55039 | Medium | 2025-10-15 | No exploit published | No public exploit | This issue affects Apache Spark versions before 3.4.4, 3.5.2 and 4.0.0. Apache Spark versions before 4.0.0, 3.5.2 and 3.4.4 use an insecure default network encryption cipher for RPC communication between nodes. When spark.network.crypto.enabled is set to true (it is set to false by default), but spark.network.crypto.cipher is not explicitly configured, Spark defaults to AES in CTR mode (AES/CTR/NoPadding), which provides encryption without authentication. This vulnerability allows a man-in-the-middle attacker to modify encrypted RPC traffic undetected by flipping bits in ciphertext, potentially compromising heartbeat messages or application data and affecting the integrity of Spark workflows. To mitigate this issue, users should either configure spark.network.crypto.cipher to AES/GCM/NoPadding to enable authenticated encryption or enable SSL encryption by setting spark.ssl.enabled to true, which provides stronger transport security. |
| CVE-2024-23945 | Medium | 2024-12-23 | No exploit published | No public exploit | Signing cookies is an application security feature that adds a digital signature to cookie data to verify its authenticity and integrity. The signature helps prevent malicious actors from modifying the cookie value, which can lead to security vulnerabilities and exploitation. Apache Hive’s service component accidentally exposes the signed cookie to the end user when there is a mismatch in signature between the current and expected cookie. Exposing the correct cookie signature can lead to further exploitation. The vulnerable CookieSigner logic was introduced in Apache Hive by HIVE-9710 (1.2.0) and in Apache Spark by SPARK-14987 (2.0.0). The affected components are the following: * org.apache.hive:hive-service * org.apache.spark:spark-hive-thriftserver_2.11 * org.apache.spark:spark-hive-thriftserver_2.12 |
| CVE-2024-39928 | High | 2024-09-25 | No exploit published | No public exploit | In Apache Linkis <= 1.5.0, a Random string security vulnerability in Spark EngineConn, random string generated by the Token when starting Py4j uses the Commons Lang's RandomStringUtils. Users are recommended to upgrade to version 1.6.0, which fixes this issue. |
| CVE-2023-22946 | Critical | 2023-04-17 | No exploit published | No public exploit | In Apache Spark versions prior to 3.4.0, applications using spark-submit can specify a 'proxy-user' to run as, limiting privileges. The application can execute code with the privileges of the submitting user, however, by providing malicious configuration-related classes on the classpath. This affects architectures relying on proxy-user, for example those using Apache Livy to manage submitted applications. Update to Apache Spark 3.4.0 or later, and ensure that spark.submit.proxyUser.allowCustomClasspathInClusterMode is set to its default of "false", and is not overridden by submitted applications. |
| CVE-2023-24451 | Medium | 2023-01-26 | No exploit published | No public exploit | A missing permission check in Jenkins Cisco Spark Notifier Plugin 1.1.1 and earlier allows attackers with Overall/Read permission to enumerate credentials IDs of credentials stored in Jenkins. |
| CVE-2022-31777 | Medium | 2022-11-01 | No exploit published | No public exploit | A stored cross-site scripting (XSS) vulnerability in Apache Spark 3.2.1 and earlier, and 3.3.0, allows remote attackers to execute arbitrary JavaScript in the web browser of a user, by including a malicious payload into the logs which would be returned in logs rendered in the UI. |
| CVE-2022-34808 | Medium | 2022-06-30 | No exploit published | No public exploit | Jenkins Cisco Spark Plugin 1.1.1 and earlier stores bearer tokens unencrypted in its global configuration file on the Jenkins controller where they can be viewed by users with access to the Jenkins controller file system. |
| CVE-2021-38296 | High | 2022-03-10 | No exploit published | No public exploit | Apache Spark supports end-to-end encryption of RPC connections via "spark.authenticate" and "spark.network.crypto.enabled". In versions 3.1.2 and earlier, it uses a bespoke mutual authentication protocol that allows for full encryption key recovery. After an initial interactive attack, this would allow someone to decrypt plaintext traffic offline. Note that this does not affect security mechanisms controlled by "spark.authenticate.enableSaslEncryption", "spark.io.encryption.enabled", "spark.ssl", "spark.ui.strictTransportSecurity". Update to Apache Spark 3.1.3 or later |
| CVE-2020-27223 | Medium | 2021-02-26 | No exploit published | Forecast only | In Eclipse Jetty 9.4.6.v20170531 to 9.4.36.v20210114 (inclusive), 10.0.0, and 11.0.0 when Jetty handles a request containing multiple Accept headers with a large number of “quality” (i.e. q) parameters, the server may enter a denial of service (DoS) state due to high CPU usage processing those quality values, resulting in minutes of CPU time exhausted processing those quality values. |
| CVE-2020-27218 | Medium | 2020-11-28 | No exploit published | No public exploit | In Eclipse Jetty version 9.4.0.RC0 to 9.4.34.v20201102, 10.0.0.alpha0 to 10.0.0.beta2, and 11.0.0.alpha0 to 11.0.0.beta2, if GZIP request body inflation is enabled and requests from different clients are multiplexed onto a single connection, and if an attacker can send a request with a body that is received entirely but not consumed by the application, then a subsequent request on the same connection will see that body prepended to its body. The attacker will not see any data but may inject data into the body of the subsequent request. |
| CVE-2020-9480 | Critical | 2020-06-23 | Mitigation candidate | Exploited | In Apache Spark 2.4.5 and earlier, a standalone resource manager's master may be configured to require authentication (spark.authenticate) via a shared secret. When enabled, however, a specially-crafted RPC to the master can succeed in starting an application's resources on the Spark cluster, even without the shared key. This can be leveraged to execute shell commands on the host machine. This does not affect Spark clusters using other resource managers (YARN, Mesos, etc). |
| CVE-2019-20445 | Critical | 2020-01-29 | No exploit published | No public exploit | HttpObjectDecoder.java in Netty before 4.1.44 allows a Content-Length header to be accompanied by a second Content-Length header, or by a Transfer-Encoding header. |
| CVE-2019-10099 | High | 2019-08-07 | No exploit published | No public exploit | Prior to Spark 2.3.3, in certain situations Spark would write user data to local disk unencrypted, even if spark.io.encryption.enabled=true. This includes cached blocks that are fetched to disk (controlled by spark.maxRemoteBlockSizeFetchToMem); in SparkR, using parallelize; in Pyspark, using broadcast and parallelize; and use of python udfs. |
| CVE-2019-10291 | High | 2019-04-04 | No exploit published | No public exploit | Jenkins Netsparker Cloud Scan Plugin 1.1.5 and older stored credentials unencrypted in its global configuration file on the Jenkins master where they could be viewed by users with access to the master file system. |
| CVE-2019-10290 | Medium | 2019-04-04 | No exploit published | No public exploit | A missing permission check in Jenkins Netsparker Cloud Scan Plugin 1.1.5 and older in the NCScanBuilder.DescriptorImpl#doValidateAPI form validation method allowed attackers with Overall/Read permission to initiate a connection to an attacker-specified server. |
| CVE-2019-10289 | Medium | 2019-04-04 | No exploit published | No public exploit | A cross-site request forgery vulnerability in Jenkins Netsparker Cloud Scan Plugin 1.1.5 and older in the NCScanBuilder.DescriptorImpl#doValidateAPI form validation method allowed attackers to initiate a connection to an attacker-specified server. |
| CVE-2018-11804 | High | 2018-10-24 | No exploit published | No public exploit | Spark's Apache Maven-based build includes a convenience script, 'build/mvn', that downloads and runs a zinc server to speed up compilation. It has been included in release branches since 1.3.x, up to and including master. This server will accept connections from external hosts by default. A specially-crafted request to the zinc server could cause it to reveal information in files readable to the developer account running the build. Note that this issue does not affect end users of Spark, only developers building Spark from source code. |
| CVE-2018-11770 | Medium | 2018-08-13 | Mitigation candidate | Exploited | 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'. |
| CVE-2018-1334 | Medium | 2018-07-12 | No exploit published | No public exploit | In Apache Spark 1.0.0 to 2.1.2, 2.2.0 to 2.2.1, and 2.3.0, when using PySpark or SparkR, it's possible for a different local user to connect to the Spark application and impersonate the user running the Spark application. |
| CVE-2017-7678 | Medium | 2017-07-12 | No exploit published | No public exploit | In Apache Spark before 2.2.0, it is possible for an attacker to take advantage of a user's trust in the server to trick them into visiting a link that points to a shared Spark cluster and submits data including MHTML to the Spark master, or history server. This data, which could contain a script, would then be reflected back to the user and could be evaluated and executed by MS Windows-based clients. It is not an attack on Spark itself, but on the user, who may then execute the script inadvertently when viewing elements of the Spark web UIs. |