CVE-2026-33012
Unbounded Cache Memory Leak in Micronaut Causes DoS
Publication date: 2026-03-20
Last updated on: 2026-03-24
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| objectcomputing | micronaut | From 4.7.0 (inc) to 4.10.17 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-770 | The product allocates a reusable resource or group of resources on behalf of an actor without imposing any intended restrictions on the size or number of resources that can be allocated. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
[{'type': 'paragraph', 'content': "CVE-2026-33012 is a denial-of-service vulnerability in the Micronaut Framework's DefaultHtmlErrorResponseBodyProvider class. This class used an unbounded ConcurrentHashMap cache to store HTML error responses without any eviction policy. If an attacker can influence exception messagesβsuch as by including request query parametersβthey can cause the cache to grow without limit by flooding it with unique error messages. This unbounded growth leads to excessive memory consumption, resulting in an OutOfMemoryError and causing the application to crash or become unavailable."}, {'type': 'paragraph', 'content': 'The vulnerability was fixed by replacing the unbounded ConcurrentHashMap with a bounded ConcurrentLinkedHashMap cache limited to 100 entries, preventing uncontrolled memory growth.'}] [1, 2]
How can this vulnerability impact me? :
[{'type': 'paragraph', 'content': "This vulnerability can be exploited remotely by attackers to cause a denial of service (DoS) condition. By sending requests that trigger exceptions with attacker-controlled messages, the attacker can cause the application's error response cache to grow without bounds, consuming all available heap memory."}, {'type': 'paragraph', 'content': 'The impact is an OutOfMemoryError that crashes or severely degrades the availability of the application, making it unavailable to legitimate users.'}] [1, 2]
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring the application for unbounded heap growth or OutOfMemoryError events caused by the caching of attacker-influenced exception messages in the DefaultHtmlErrorResponseBodyProvider.
One way to detect exploitation attempts is to observe if the cache size in the DefaultHtmlErrorResponseBodyProvider grows uncontrollably when the application processes requests with unique exception messages.
Since the vulnerability involves caching error responses with attacker-controlled content, you can monitor application logs for repeated or unusual exception messages containing request query parameters.
Specific commands depend on your environment, but general suggestions include:
- Use Java monitoring tools like jcmd or jmap to check heap usage and detect OutOfMemoryError occurrences.
- Use application-specific debugging or testing endpoints (if available) to inspect the cache size via the newly added getCache() method in DefaultHtmlErrorResponseBodyProvider.
- Monitor logs for repeated exceptions with unique messages, especially those including request URIs or query parameters.
What immediate steps should I take to mitigate this vulnerability?
The immediate mitigation step is to upgrade the Micronaut Framework to version 4.10.17 or later, where the vulnerability has been fixed by replacing the unbounded ConcurrentHashMap cache with a bounded ConcurrentLinkedHashMap cache that limits the cache size to 100 entries.
This fix prevents unbounded heap growth by introducing a cache eviction mechanism, effectively stopping attackers from causing denial-of-service via flooding the cache with unique error messages.
If upgrading immediately is not possible, consider implementing application-level controls to sanitize or limit exception messages that include attacker-controlled input, and monitor heap usage closely to detect potential exploitation.