Overview 13 matches · 0 protected · 2 exploited · 1 CISA KEV · 3 public PoC · 2 EPSS ≥ 0.5
Protected by Waratek
0
0.0%
Rule in development
0
0.0%
Mitigation candidate
3
23.1%
No exploit published
10
76.9%
blocked by ARMR today
0
0.0%
partly blocked
0
0.0%
not blocked
13
100.0%
not established
0
0.0%
unrecorded
0
0.0%
split by
peak 4 / year
20172
No exploit published2
High1
Medium1
not blocked2
No public exploit2
20184
Mitigation candidate1
No exploit published3
High2
Medium2
not blocked4
Exploited1
No public exploit3
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
20221
No exploit published1
Medium1
not blocked1
No public exploit1
20232
Mitigation candidate1
No exploit published1
High2
not blocked2
Exploited1
Proof of concept only1
2017201820192020202120222023
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| 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-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-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-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-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-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. |