High Core_2.13 CVEs

14 CVEs, 1 exploited, 1 protected by Waratek

Look up CVE IDs Status Exploitation Severity

Reset

Overview 14 matches · 1 protected · 1 exploited · 1 CISA KEV · 2 public PoC · 1 EPSS ≥ 0.5

14matches 1protected7.1% 1exploited7.1% 1CISA KEV7.1% 2public PoC14.3% 1EPSS ≥ 0.57.1%

Protected by Waratek 1 7.1% Rule in development 0 0.0% Mitigation candidate 2 14.3% No exploit published 11 78.6%

Critical 0 0.0% High 14 100.0% Medium 0 0.0% Low 0 0.0% None 0 0.0% Unknown 0 0.0%

blocked by ARMR today 1 7.1% partly blocked 0 0.0% not blocked 13 92.9% not established 0 0.0% unrecorded 0 0.0%

Exploited 1 7.1% Working exploit published 1 7.1% Proof of concept only 1 7.1% Forecast only 0 0.0% No public exploit 11 78.6%

split by StatusSeverityProtectionExploit maturity peak 7 / quarter

Q4 201 No exploit published1 High1 not blocked1 No public exploit1 Q1 211 No exploit published1 High1 not blocked1 No public exploit1 Q2 210 Q3 210 Q4 211 Mitigation candidate1 High1 not blocked1 Working exploit published1 Q1 220 Q2 220 Q3 220 Q4 220 Q1 231 No exploit published1 High1 not blocked1 Proof of concept only1 Q2 230 Q3 230 Q4 232 Mitigation candidate1 No exploit published1 High2 not blocked2 Exploited1 No public exploit1 Q1 240 Q2 240 Q3 240 Q4 240 Q1 250 Q2 250 Q3 250 Q4 250 Q1 261 Protected by Waratek1 High1 blocked by ARMR today1 No public exploit1 Q2 260 Q3 267 No exploit published7 High7 not blocked7 No public exploit7

Q1 21Q3 21Q1 22Q3 22Q1 23Q3 23Q1 24Q3 24Q1 25Q3 25Q1 26Q3 26

14 matches Sign in to download these CVEs as CSV or JSON, or to follow them in a feed.

CVE	Severity	Published▾	Status	Exploitation	Description
CVE-2026-88975	High	2026-09-15	No exploit published	No public exploit	Http4s is a Scala interface for HTTP services. Prior to 0.23.37 and 1.0.0-M48, Ember’s HTTP/2 read loop parses a frame’s 24-bit declared length but waits to buffer the entire payload before comparing it with SETTINGS_MAX_FRAME_SIZE. An unauthenticated peer can declare a payload near 16 MiB on a connection where Ember advertised 16 KiB and either complete or slowly stream it, causing up to 1024-fold memory amplification per connection before processFrame can reject the frame. The shared H2Connection.readLoop affects withHttp2 servers and clients, while HTTP/2-disabled configurations are unaffected, and the patch rejects oversized frames before buffering their payloads. This issue is fixed in versions 0.23.37 and 1.0.0-M48.
CVE-2026-69218	High	2026-09-15	No exploit published	No public exploit	Http4s is a Scala interface for HTTP services. Prior to 0.23.35 and 1.0.0-M47, When Ember receives an HTTP/2 HEADERS or PUSH_PROMISE frame without END_HEADERS, H2Connection buffers the header block and subsequent CONTINUATION fragments without a size bound. A remote peer can keep an incomplete block open and exhaust heap memory before request decoding, affecting an ember-server or ember-client configured with withHttp2. The remediation tracks accumulated size against SETTINGS_MAX_HEADER_LIST_SIZE derived from EmberServerBuilder.maxHeaderSize or EmberClientBuilder.maxResponseHeaderSize, sends GOAWAY when the limit is exceeded, and applies receiveHeadersTimeout to incomplete blocks. This issue is fixed in versions 0.23.35 and 1.0.0-M47.
CVE-2026-69213	High	2026-09-15	No exploit published	No public exploit	Http4s is a Scala interface for HTTP services. Prior to 0.23.35 and 1.0.0-M47, Ember HTTP/2 serializes outbound frames through one unbounded queue consumed by writeLoop. When the peer stops reading, an unauthenticated HTTP/2 client can continue sending PING, SETTINGS, or DATA frames that cause Ember to enqueue acknowledgments or WINDOW_UPDATE frames faster than the writer drains them, exhausting heap memory on a server built with withHttp2. The shared behavior also affects an ember-client connected to a hostile HTTP/2 server, and the patch replaces the unbounded path with bounded, backpressured outbound queues. This issue is fixed in versions 0.23.35 and 1.0.0-M47.
CVE-2026-69205	High	2026-09-15	No exploit published	No public exploit	Http4s is a Scala interface for HTTP services. Prior to 0.23.35 and 1.0.0-M47, Ember’s HeaderP.parse uses a case-sensitive substring test for the Transfer-Encoding value and decodes header bytes with the platform default charset. Values such as Chunked are not recognized, values such as notchunked are incorrectly accepted, and Unicode case folding can turn a Kelvin-sign byte sequence into a match when UTF-8 is used. Intermediaries that apply RFC-compliant token and charset rules can therefore disagree with Ember’s Content-Length or zero-length framing, enabling TE.CL or TE.0 request smuggling, access-control bypass, cross-user request hijacking, and cache poisoning on the server path. Response smuggling through an ember-client gateway requires a malicious or compromised upstream. This issue is fixed in versions 0.23.35 and 1.0.0-M47.
CVE-2026-69203	High	2026-09-15	No exploit published	No public exploit	Http4s is a Scala interface for HTTP services. Prior to 0.23.35 and 1.0.0-M47, An Ember server with HTTP/2 enabled through withHttp2 does not enforce SETTINGS_MAX_CONCURRENT_STREAMS for peer-created streams. One unauthenticated connection can open an unbounded number of streams, each retaining per-stream state until heap exhaustion. The same unchecked allocation is reachable in an ember-client through server-initiated PUSH_PROMISE frames because enablePush is not enforced. This issue is fixed in versions 0.23.35 and 1.0.0-M47.
CVE-2026-69202	High	2026-09-15	No exploit published	No public exploit	Http4s is a Scala interface for HTTP services. Prior to 0.23.35 and 1.0.0-M47, Ember’s HTTP/2 flow-control window is replenished according to bytes received from the network rather than bytes consumed by the application, while each stream stores DATA in an unbounded channel. A hostile peer can therefore send a body faster than a slow or non-draining application consumes it, retaining payloads in heap on an ember-server or ember-client configured with withHttp2. The patch bounds the per-stream H2Connection body channel so application consumption applies backpressure. This issue is fixed in versions 0.23.35 and 1.0.0-M47.
CVE-2026-54556	High	2026-08-26	No exploit published	No public exploit	Http4s is a Scala interface for HTTP services. Prior to 0.23.35 and 1.0.0-M47, an unauthenticated HTTP/2 peer can cause an out-of-memory denial of service in the Ember backend with HTTP/2 enabled. The Hpack wrapper in ember-core/shared/src/main/scala/org/http4s/ember/core/h2/Hpack.scala concatenates HEADERS and CONTINUATION frame fragments and decodes them into a single List, but maxHeaderSize accounting does not include indexed headers or HPACK per-header overhead. A small compressed header block can therefore expand into a much larger decoded representation that remains in memory for processing. Servers exposed to untrusted HTTP/2 traffic and clients directed to an untrusted HTTP/2 server are affected, and concurrent malicious connections can exhaust the process heap. This issue is fixed in versions 0.23.35 and 1.0.0-M47.
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-50730	High	2023-12-22	No exploit published	No public exploit	Grackle is a GraphQL server written in functional Scala, built on the Typelevel stack. The GraphQL specification requires that GraphQL fragments must not form cycles, either directly or indirectly. Prior to Grackle version 0.18.0, that requirement wasn't checked, and queries with cyclic fragments would have been accepted for type checking and compilation. The attempted compilation of such fragments would result in a JVM `StackOverflowError` being thrown. Some knowledge of an applications GraphQL schema would be required to construct such a query, however no knowledge of any application-specific performance or other behavioural characteristics would be needed. Grackle uses the cats-parse library for parsing GraphQL queries. Prior to version 0.18.0, Grackle made use of the cats-parse `recursive` operator. However, `recursive` is not currently stack safe. `recursive` was used in three places in the parser: nested selection sets, nested input values (lists and objects), and nested list type declarations. Consequently, queries with deeply nested selection sets, input values or list types could be constructed which exploited this, causing a JVM `StackOverflowException` to be thrown during parsing. Because this happens very early in query processing, no specific knowledge of an applications GraphQL schema would be required to construct such a query. The possibility of small queries resulting in stack overflow is a potential denial of service vulnerability. This potentially affects all applications using Grackle which have untrusted users. Both stack overflow issues have been resolved in the v0.18.0 release of Grackle. As a workaround, users could interpose a sanitizing layer in between untrusted input and Grackle query processing.
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

Severity

Published▾

Status

Exploitation

Description

CVE-2026-88975

High

2026-09-15

No exploit published

No public exploit

Http4s is a Scala interface for HTTP services. Prior to 0.23.37 and 1.0.0-M48, Ember’s HTTP/2 read loop parses a frame’s 24-bit declared length but waits to buffer the entire payload before comparing it with SETTINGS_MAX_FRAME_SIZE. An unauthenticated peer can declare a payload near 16 MiB on a connection where Ember advertised 16 KiB and either complete or slowly stream it, causing up to 1024-fold memory amplification per connection before processFrame can reject the frame. The shared H2Connection.readLoop affects withHttp2 servers and clients, while HTTP/2-disabled configurations are unaffected, and the patch rejects oversized frames before buffering their payloads. This issue is fixed in versions 0.23.37 and 1.0.0-M48.

CVE-2026-69218

High

2026-09-15

No exploit published

No public exploit

Http4s is a Scala interface for HTTP services. Prior to 0.23.35 and 1.0.0-M47, When Ember receives an HTTP/2 HEADERS or PUSH_PROMISE frame without END_HEADERS, H2Connection buffers the header block and subsequent CONTINUATION fragments without a size bound. A remote peer can keep an incomplete block open and exhaust heap memory before request decoding, affecting an ember-server or ember-client configured with withHttp2. The remediation tracks accumulated size against SETTINGS_MAX_HEADER_LIST_SIZE derived from EmberServerBuilder.maxHeaderSize or EmberClientBuilder.maxResponseHeaderSize, sends GOAWAY when the limit is exceeded, and applies receiveHeadersTimeout to incomplete blocks. This issue is fixed in versions 0.23.35 and 1.0.0-M47.

CVE-2026-69213

High

2026-09-15

No exploit published

No public exploit

Http4s is a Scala interface for HTTP services. Prior to 0.23.35 and 1.0.0-M47, Ember HTTP/2 serializes outbound frames through one unbounded queue consumed by writeLoop. When the peer stops reading, an unauthenticated HTTP/2 client can continue sending PING, SETTINGS, or DATA frames that cause Ember to enqueue acknowledgments or WINDOW_UPDATE frames faster than the writer drains them, exhausting heap memory on a server built with withHttp2. The shared behavior also affects an ember-client connected to a hostile HTTP/2 server, and the patch replaces the unbounded path with bounded, backpressured outbound queues. This issue is fixed in versions 0.23.35 and 1.0.0-M47.

CVE-2026-69205

High

2026-09-15

No exploit published

No public exploit

Http4s is a Scala interface for HTTP services. Prior to 0.23.35 and 1.0.0-M47, Ember’s HeaderP.parse uses a case-sensitive substring test for the Transfer-Encoding value and decodes header bytes with the platform default charset. Values such as Chunked are not recognized, values such as notchunked are incorrectly accepted, and Unicode case folding can turn a Kelvin-sign byte sequence into a match when UTF-8 is used. Intermediaries that apply RFC-compliant token and charset rules can therefore disagree with Ember’s Content-Length or zero-length framing, enabling TE.CL or TE.0 request smuggling, access-control bypass, cross-user request hijacking, and cache poisoning on the server path. Response smuggling through an ember-client gateway requires a malicious or compromised upstream. This issue is fixed in versions 0.23.35 and 1.0.0-M47.

CVE-2026-69203

High

2026-09-15

No exploit published

No public exploit

Http4s is a Scala interface for HTTP services. Prior to 0.23.35 and 1.0.0-M47, An Ember server with HTTP/2 enabled through withHttp2 does not enforce SETTINGS_MAX_CONCURRENT_STREAMS for peer-created streams. One unauthenticated connection can open an unbounded number of streams, each retaining per-stream state until heap exhaustion. The same unchecked allocation is reachable in an ember-client through server-initiated PUSH_PROMISE frames because enablePush is not enforced. This issue is fixed in versions 0.23.35 and 1.0.0-M47.

CVE-2026-69202

High

2026-09-15

No exploit published

No public exploit

Http4s is a Scala interface for HTTP services. Prior to 0.23.35 and 1.0.0-M47, Ember’s HTTP/2 flow-control window is replenished according to bytes received from the network rather than bytes consumed by the application, while each stream stores DATA in an unbounded channel. A hostile peer can therefore send a body faster than a slow or non-draining application consumes it, retaining payloads in heap on an ember-server or ember-client configured with withHttp2. The patch bounds the per-stream H2Connection body channel so application consumption applies backpressure. This issue is fixed in versions 0.23.35 and 1.0.0-M47.

CVE-2026-54556

High

2026-08-26

No exploit published

No public exploit

Http4s is a Scala interface for HTTP services. Prior to 0.23.35 and 1.0.0-M47, an unauthenticated HTTP/2 peer can cause an out-of-memory denial of service in the Ember backend with HTTP/2 enabled. The Hpack wrapper in ember-core/shared/src/main/scala/org/http4s/ember/core/h2/Hpack.scala concatenates HEADERS and CONTINUATION frame fragments and decodes them into a single List, but maxHeaderSize accounting does not include indexed headers or HPACK per-header overhead. A small compressed header block can therefore expand into a much larger decoded representation that remains in memory for processing. Servers exposed to untrusted HTTP/2 traffic and clients directed to an untrusted HTTP/2 server are affected, and concurrent malicious connections can exhaust the process heap. This issue is fixed in versions 0.23.35 and 1.0.0-M47.

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-50730

High

2023-12-22

No exploit published

No public exploit

Grackle is a GraphQL server written in functional Scala, built on the Typelevel stack. The GraphQL specification requires that GraphQL fragments must not form cycles, either directly or indirectly. Prior to Grackle version 0.18.0, that requirement wasn't checked, and queries with cyclic fragments would have been accepted for type checking and compilation. The attempted compilation of such fragments would result in a JVM `StackOverflowError` being thrown. Some knowledge of an applications GraphQL schema would be required to construct such a query, however no knowledge of any application-specific performance or other behavioural characteristics would be needed. Grackle uses the cats-parse library for parsing GraphQL queries. Prior to version 0.18.0, Grackle made use of the cats-parse `recursive` operator. However, `recursive` is not currently stack safe. `recursive` was used in three places in the parser: nested selection sets, nested input values (lists and objects), and nested list type declarations. Consequently, queries with deeply nested selection sets, input values or list types could be constructed which exploited this, causing a JVM `StackOverflowException` to be thrown during parsing. Because this happens very early in query processing, no specific knowledge of an applications GraphQL schema would be required to construct such a query. The possibility of small queries resulting in stack overflow is a potential denial of service vulnerability. This potentially affects all applications using Grackle which have untrusted users. Both stack overflow issues have been resolved in the v0.18.0 release of Grackle. As a workaround, users could interpose a sanitizing layer in between untrusted input and Grackle query processing.

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.