CVE-2026-33012: Micronaut Framework DoS Vulnerability

CVE-2026-33012 Overview

CVE-2026-33012 is a Denial of Service vulnerability affecting the Micronaut Framework, a JVM-based full stack Java framework designed for building modular, easily testable JVM applications. The vulnerability exists in the DefaultHtmlErrorResponseBodyProvider component, which uses an unbounded ConcurrentHashMap cache without any eviction policy. When an application throws exceptions containing attacker-controlled content (such as request query parameters), remote attackers can exploit this flaw to cause unbounded heap growth, resulting in an OutOfMemoryError and complete service disruption.

Critical Impact

Remote attackers can exploit this vulnerability to cause Denial of Service through memory exhaustion without requiring authentication, potentially crashing production JVM applications.

Affected Products

• Objectcomputing Micronaut versions 4.7.0 through 4.10.16
• Applications using the DefaultHtmlErrorResponseBodyProvider component
• JVM applications that expose error messages containing user-controlled input

Discovery Timeline

• 2026-03-20 - CVE-2026-33012 published to NVD
• 2026-03-24 - Last updated in NVD database

Technical Details for CVE-2026-33012

Vulnerability Analysis

This vulnerability represents a classic Resource Exhaustion issue (CWE-770: Allocation of Resources Without Limits or Throttling). The Micronaut Framework's DefaultHtmlErrorResponseBodyProvider component maintains an internal cache using a ConcurrentHashMap to store processed error response bodies. The fundamental flaw is that this cache lacks any size limits or eviction policy, allowing it to grow indefinitely.

When an application throws an exception that includes attacker-influenced content in its message (such as query parameters, request headers, or other user input), each unique exception message creates a new entry in the cache. An attacker can exploit this by systematically sending requests with varying parameters that trigger exceptions, causing the cache to accumulate entries until the JVM exhausts available heap memory.

The attack is particularly effective because it requires no authentication and can be executed remotely over the network. The availability impact is complete service disruption, though confidentiality and integrity remain unaffected since this is purely a resource exhaustion attack.

Root Cause

The root cause lies in the design of the DefaultHtmlErrorResponseBodyProvider class, which caches HTML error response bodies keyed by exception messages. The cache was implemented using a ConcurrentHashMap for thread-safe access but without implementing any bounds checking, maximum size constraints, or time-based eviction policies. This architectural oversight allows the cache to grow unbounded when processing exceptions with unique messages.

Attack Vector

The attack vector is network-based and requires no privileges or user interaction. An attacker can exploit this vulnerability by sending crafted HTTP requests designed to trigger exceptions with unique messages. For example, if the application includes query parameter values in exception messages, an attacker could send thousands of requests with different parameter values, each creating a new cache entry.

The vulnerability exploitation flow works as follows:

1. Attacker identifies an endpoint that can trigger exceptions containing user input
2. Attacker sends requests with varying input values (e.g., different query parameters)
3. Each unique exception message creates a new entry in the unbounded cache
4. Repeated requests cause continuous heap growth
5. Eventually, the JVM runs out of memory and throws OutOfMemoryError
6. The application becomes unavailable, achieving Denial of Service

Detection Methods for CVE-2026-33012

Indicators of Compromise

• Abnormal memory growth patterns in JVM heap utilization metrics
• Increasing number of entries in application error response caches
• Elevated request rates to endpoints that commonly generate error responses
• OutOfMemoryError exceptions in application logs with heap space exhaustion
• Unusual patterns of requests with varying query parameters targeting the same endpoints

Detection Strategies

• Monitor JVM heap memory utilization for sustained growth without corresponding garbage collection relief
• Implement alerting on OutOfMemoryError occurrences in application logs
• Track request patterns for anomalous volumes of error-generating requests from single sources
• Analyze application memory dumps for oversized ConcurrentHashMap cache objects
• Review request logs for patterns of systematically varied parameters targeting error-prone endpoints

Monitoring Recommendations

• Configure JVM monitoring to alert when heap usage exceeds 80% for extended periods
• Implement rate limiting on endpoints known to generate error responses
• Set up application performance monitoring (APM) to track cache sizes in Micronaut components
• Enable garbage collection logging to identify memory pressure patterns
• Monitor request error rates and correlate with memory utilization spikes

How to Mitigate CVE-2026-33012

Immediate Actions Required

• Upgrade Micronaut Framework to version 4.10.17 or later immediately
• If immediate upgrade is not possible, implement rate limiting on all public endpoints
• Review application code for exception messages that include user-controlled input
• Monitor memory utilization closely until patching is complete
• Consider implementing Web Application Firewall (WAF) rules to limit request rates

Patch Information

The vulnerability has been fixed in Micronaut Framework version 4.10.17. The fix introduces proper cache eviction policies and size limits to the DefaultHtmlErrorResponseBodyProvider component. Organizations should upgrade to this version or later to fully remediate the vulnerability.

For detailed information about the fix, refer to the GitHub Commit Details and the GitHub Security Advisory GHSA-2hcp-gjrf-7fhc. The patched version is available at the GitHub Release v4.10.17.

Workarounds

• Implement request rate limiting at the load balancer or reverse proxy level to reduce attack throughput
• Configure JVM heap size limits with appropriate garbage collection tuning to delay exhaustion
• Sanitize user input before including it in exception messages to reduce cache key uniqueness
• Deploy a custom error handler that bypasses DefaultHtmlErrorResponseBodyProvider for user-facing errors
• Implement application-level circuit breakers to prevent cascading failures during memory pressure

# JVM configuration to help mitigate memory exhaustion (temporary workaround only)
# Add these JVM options to your application startup
-Xmx4g                          # Set maximum heap size
-XX:+HeapDumpOnOutOfMemoryError # Generate heap dump on OOM for analysis
-XX:HeapDumpPath=/var/log/heapdumps/
-XX:+UseG1GC                    # Use G1 garbage collector for better memory management
-XX:MaxGCPauseMillis=200        # Target GC pause time