CVE-2022-21700: Memory leak in micronaut-core

io.micronaut:micronaut-http Updated 02 Oct 2025

Summary

21/01/2022
Yes i
Moderate
5.3

CVE-2022-21700: Memory leak in micronaut-core. Affects io.micronaut:micronaut-http versions < 3.2.7. Fixed in 3.2.7. 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 micronaut-core package is a core component of the Micronaut framework, which is a modern, JVM-based, full-stack framework for building modular, easily testable microservice and serverless applications. It provides features such as dependency injection, AOP, and declarative HTTP clients and servers. The package io.micronaut:micronaut-http is specifically responsible for handling HTTP-related functionality.

Vulnerability Detail

This vulnerability (CVE-2022-21700) in micronaut-core allows an attacker to cause a memory leak by sending an invalid Content Type header. The issue arises from the incorrect usage of DefaultArgumentConversionContext in static state. When an invalid Content Type header is received, the memory leak occurs in DefaultArgumentConversionContext. This vulnerability can potentially lead to resource exhaustion and denial of service (DoS) attacks.

How To Fix

Latest published version: 5.2.19 as of 23 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

3.2.7

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

If updating the package is not immediately feasible, a workaround can be implemented by replacing the default content type binder in an existing Micronaut application. The following code snippet demonstrates how to create a custom FixedRequestBinderRegistry class that replaces the default binder:

package example;

import java.util.List;
import io.micronaut.context.annotation.Replaces;
import io.micronaut.core.convert.ConversionService;
import io.micronaut.http.MediaType;
import io.micronaut.http.bind.DefaultRequestBinderRegistry;
import io.micronaut.http.bind.binders.RequestArgumentBinder;
import jakarta.inject.Singleton;

@Singleton
@Replaces(DefaultRequestBinderRegistry.class)
class FixedRequestBinderRegistry extends DefaultRequestBinderRegistry {

    public FixedRequestBinderRegistry(ConversionService conversionService,
                                      List<RequestArgumentBinder> binders) {
        super(conversionService, binders);
    }

    @Override
    protected void registerDefaultConverters(ConversionService<?> conversionService) {
        super.registerDefaultConverters(conversionService);
        conversionService.addConverter(CharSequence.class, MediaType.class, charSequence -> {
            try {
                return MediaType.of(charSequence);
            } catch (IllegalArgumentException e) {
                return null;
            }
        });
    }
}

This workaround replaces the default content type binder and handles the conversion of the CharSequence to MediaType in a way that prevents the memory leak.

Conclusion

The vulnerability (CVE-2022-21700) in micronaut-core allows for a memory leak when an invalid Content Type header is received. It is crucial to update the micronaut-http package to version 3.2.7 or above to mitigate this vulnerability. If immediate package update is not possible, a workaround can be implemented by replacing the default content type binder. For further support on vulnerability remediation, please contact DevNack.com.

See every vulnerability recorded for io.micronaut:micronaut-http →

Share this vulnerability

FAQ

This vulnerability can lead to a memory leak in the micronaut-core package, potentially resulting in resource exhaustion and denial of service (DoS) attacks.

To fix this vulnerability, update the micronaut-http package to version 3.2.7 or above.

Yes, a workaround is available by replacing the default content type binder in an existing Micronaut application with a custom implementation.

Yes, this vulnerability can be exploited remotely by sending an invalid Content Type header.

There is no known instance of this vulnerability being exploited at the moment.

How To Fix

Latest published version: 5.2.19 as of 23 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

3.2.7

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