CVE-2021-21294: Unbounded connection acceptance in http4s-blaze-server

Summary

02/02/2021
Yes i
High
7.5

CVE-2021-21294: Unbounded connection acceptance in http4s-blaze-server. Affects org.http4s:http4s-blaze-server_2.12 versions < 0.21.17. Fixed in 0.21.17. How to fix ↓

Free scan

Check if this vulnerability affects your application

Upload a manifest or SBOM and we'll show whether you're affected, plus every other risky package in the same scan.

Check my app free

No signup required · Results in about 60 seconds

Upload your dependency manifest or SBOM

Drag & drop your file here or

Java Javascript PHP Python Go Rust Ruby Dart C/C++ Elixir CycloneDX SPDX

Upload a supported dependency manifest or SBOM. No installation or source-code access required.

See supported files and SBOM formats
SBOM sbom.json · bom.json · bom.xml · *.spdx.json · *.cdx.json · *.cdx.xml
Java pom.xml · gradle.lockfile · buildscript-gradle.lockfile
Javascript package-lock.json · yarn.lock · pnpm-lock.yaml
PHP composer.lock
Python poetry.lock · requirements.txt · Pipfile.lock
Go go.mod
Rust Cargo.lock
Ruby Gemfile.lock
Dart pubspec.lock
C/C++ conan.lock
Elixir mix.lock
Enter your work email to receive your report link.

Verify your email to view the full report and start 30 days of continuous monitoring. No credit card required.

Sponsored Devnack Your last release was probably never penetration tested Manual testing by engineers who build software, not an auditor's checklist. Trusted by teams at Swift and Google Talk to Devnack

Background

The http4s-blaze-server package is a library used for building HTTP servers in the http4s framework. It relies on the blaze-core library for handling connections. The vulnerability in question allows the blaze-core library to accept connections without any limit, leading to potential resource exhaustion and degraded service performance. This vulnerability affects versions 0.0.1 to 0.21.17 of the http4s-blaze-server package.

Vulnerability Detail

The vulnerability arises from the fact that blaze-core accepts connections without any bounds on its selector pool. This means that even if a service is unable to handle its current request load, incoming connections will still be accepted and added to an unbounded queue. Each connection allocates a socket handle, which drains a scarce operating system resource. This can result in degraded service performance and may also impact higher-level circuit breakers that rely on detecting failed connections.

How To Fix

Latest published version: 1.0-57-0368053 as of 22 Oct 2026

Upgrading to it may include breaking changes; the version below is the minimum fixed release for this vulnerability.

If you need the minimum change

0.21.17

This is the first release that contains the fix.

Tip — Not sure which version your app runs? Vulert can match this fix to it. Scan free →

Workaround

There are a few workarounds available:

  1. Use an Nginx side-car as a reverse proxy for the local http4s-blaze-server instance. Nginx provides connection limiting semantics that respect backpressure and can help mitigate the impact of this vulnerability.
  2. Consider using alternative backends such as http4s-ember-server, http4s-jetty, or http4s-tomcat. These backends have their own performance characteristics and limitations but may be suitable depending on the specific use case.

Conclusion

The vulnerability in http4s-blaze-server can lead to resource exhaustion and degraded service performance. It is crucial to update to the fixed versions and set appropriate limits on the number of open connections. If you have any further questions or need assistance with vulnerability remediation, please contact DevNack.com.

See every vulnerability recorded for org.http4s:http4s-blaze-server_2.12 →

Share this vulnerability

FAQ

The vulnerability can lead to resource exhaustion and degraded service performance. It can also confound higher-level circuit breakers that rely on detecting failed connections.

Update to version 0.21.18, 0.22.0-M3, or 1.0.0-M16 of the http4s-blaze-server package and set the 'maxConnections' property to limit the number of open connections.

Yes, you can use an Nginx side-car as a reverse proxy or consider using alternative backends such as http4s-ember-server, http4s-jetty, or http4s-tomcat.

No, the NIO2 backend does not respect the 'maxConnections' property. Its use is deprecated in http4s-0.21 and will be removed in http4s-0.22.

Yes, the default limit is 1024. However, it is recommended to set a reasonable limit based on the expected load and available resources.

How To Fix

Latest published version: 1.0-57-0368053 as of 22 Oct 2026

Upgrading to it may include breaking changes; the version below is the minimum fixed release for this vulnerability.

If you need the minimum change

0.21.17

This is the first release that contains the fix.

Tip — Not sure which version your app runs? Vulert can match this fix to it. Scan free →

Subscribe to Vulert on Telegram
Daily digest of new CVEs, critical and high severity, affected packages and fixes — plus a weekly roundup.
Join the channel →
Help improve this record
Report an issue or send feedback