High Core_2.11 CVEs
11 CVEs, 1 exploited, 2 protected by Waratek
Overview 11 matches · 2 protected · 1 exploited · 1 CISA KEV · 2 public PoC · 1 EPSS ≥ 0.5
Protected by Waratek
2
18.2%
Rule in development
0
0.0%
Mitigation candidate
2
18.2%
No exploit published
7
63.6%
blocked by ARMR today
2
18.2%
partly blocked
0
0.0%
not blocked
9
81.8%
not established
0
0.0%
unrecorded
0
0.0%
split by
peak 2 / year
20172
Protected by Waratek1
No exploit published1
High2
blocked by ARMR today1
not blocked1
No public exploit2
20182
No exploit published2
High2
not blocked2
No public exploit2
20191
No exploit published1
High1
not blocked1
No public exploit1
20201
No exploit published1
High1
not blocked1
No public exploit1
20212
Mitigation candidate1
No exploit published1
High2
not blocked2
Working exploit published1
No public exploit1
20220
20232
Mitigation candidate1
No exploit published1
High2
not blocked2
Exploited1
Proof of concept only1
20240
20250
20261
Protected by Waratek1
High1
blocked by ARMR today1
No public exploit1
2017201820192020202120222023202420252026
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2025-54920 | High | 2026-03-16 | Protected by Waratek | No public exploit | This issue affects Apache Spark: before 3.5.7 and 4.0.1. Users are recommended to upgrade to version 3.5.7 or 4.0.1 and above, which fixes the issue. Summary Apache Spark 3.5.4 and earlier versions contain a code execution vulnerability in the Spark History Web UI due to overly permissive Jackson deserialization of event log data. This allows an attacker with access to the Spark event logs directory to inject malicious JSON payloads that trigger deserialization of arbitrary classes, enabling command execution on the host running the Spark History Server. Details The vulnerability arises because the Spark History Server uses Jackson polymorphic deserialization with @JsonTypeInfo.Id.CLASS on SparkListenerEvent objects, allowing an attacker to specify arbitrary class names in the event JSON. This behavior permits instantiating unintended classes, such as org.apache.hive.jdbc.HiveConnection, which can perform network calls or other malicious actions during deserialization. The attacker can exploit this by injecting crafted JSON content into the Spark event log files, which the History Server then deserializes on startup or when loading event logs. For example, the attacker can force the History Server to open a JDBC connection to a remote attacker-controlled server, demonstrating remote command injection capability. Proof of Concept: 1. Run Spark with event logging enabled, writing to a writable directory (spark-logs). 2. Inject the following JSON at the beginning of an event log file: { "Event": "org.apache.hive.jdbc.HiveConnection", "uri": "jdbc:hive2://<IP>:<PORT>/", "info": { "hive.metastore.uris": "thrift://<IP>:<PORT>" } } 3. Start the Spark History Server with logs pointing to the modified directory. 4. The Spark History Server initiates a JDBC connection to the attacker’s server, confirming the injection. Impact An attacker with write access to Spark event logs can execute arbitrary code on the server running the History Server, potentially compromising the entire system. |
| CVE-2023-44487 | High | 2023-10-10 | Mitigation candidate | Exploited | The HTTP/2 protocol allows a denial of service (server resource consumption) because request cancellation can reset many streams quickly, as exploited in the wild in August through October 2023. |
| CVE-2023-22465 | High | 2023-01-04 | No exploit published | Proof of concept only | Http4s is a Scala interface for HTTP services. Starting with version 0.1.0 and prior to versions 0.21.34, 0.22.15, 0.23.17, and 1.0.0-M38, the `User-Agent` and `Server` header parsers are susceptible to a fatal error on certain inputs. In http4s, modeled headers are lazily parsed, so this only applies to services that explicitly request these typed headers. Fixes are released in 0.21.34, 0.22.15, 0.23.17, and 1.0.0-M38. As a workaround, use the weakly typed header interface. |
| CVE-2021-42697 | High | 2021-11-02 | Mitigation candidate | Working exploit published | Akka HTTP 10.1.x before 10.1.15 and 10.2.x before 10.2.7 can encounter stack exhaustion while parsing HTTP headers, which allows a remote attacker to conduct a Denial of Service attack by sending a User-Agent header with deeply nested comments. |
| CVE-2021-21293 | High | 2021-02-02 | No exploit published | No public exploit | blaze is a Scala library for building asynchronous pipelines, with a focus on network IO. All servers running blaze-core before version 0.14.15 are affected by a vulnerability in which unbounded connection acceptance leads to file handle exhaustion. Blaze, accepts connections unconditionally on a dedicated thread pool. This has the net effect of amplifying degradation in services that are unable to handle their current request load, since incoming connections are still accepted and added to an unbounded queue. Each connection allocates a socket handle, which drains a scarce OS resource. This can also confound higher level circuit breakers which work based on detecting failed connections. The vast majority of affected users are using it as part of http4s-blaze-server <= 0.21.16. http4s provides a mechanism for limiting open connections, but is enforced inside the Blaze accept loop, after the connection is accepted and the socket opened. Thus, the limit only prevents the number of connections which can be simultaneously processed, not the number of connections which can be held open. The issue is fixed in version 0.14.15 for "NIO1SocketServerGroup". A "maxConnections" parameter is added, with a default value of 512. Concurrent connections beyond this limit are rejected. To run unbounded, which is not recommended, set a negative number. The "NIO2SocketServerGroup" has no such setting and is now deprecated. There are several possible workarounds described in the refrenced GitHub Advisory GHSA-xmw9-q7x9-j5qc. |
| CVE-2020-7780 | High | 2020-11-27 | No exploit published | No public exploit | This affects the package com.softwaremill.akka-http-session:core_2.13 before 0.5.11; the package com.softwaremill.akka-http-session:core_2.12 before 0.5.11; the package com.softwaremill.akka-http-session:core_2.11 before 0.5.11. For older versions, endpoints protected by randomTokenCsrfProtection could be bypassed with an empty X-XSRF-TOKEN header and an empty XSRF-TOKEN cookie. |
| 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-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-16131 | High | 2018-08-30 | No exploit published | No public exploit | The decodeRequest and decodeRequestWith directives in Lightbend Akka HTTP 10.1.x through 10.1.4 and 10.0.x through 10.0.13 allow remote attackers to cause a denial of service (memory consumption and daemon crash) via a ZIP bomb. |
| CVE-2017-1000118 | High | 2017-10-05 | No exploit published | No public exploit | Akka HTTP versions <= 10.0.5 Illegal Media Range in Accept Header Causes StackOverflowError Leading to Denial of Service |
| CVE-2017-12612 | High | 2017-09-13 | Protected by Waratek | No public exploit | In Apache Spark 1.6.0 until 2.1.1, the launcher API performs unsafe deserialization of data received by its socket. This makes applications launched programmatically using the launcher API potentially vulnerable to arbitrary code execution by an attacker with access to any user account on the local machine. It does not affect apps run by spark-submit or spark-shell. The attacker would be able to execute code as the user that ran the Spark application. Users are encouraged to update to version 2.2.0 or later. |