CVE-2022-2053
published 2022-08-05CVE-2022-2053: When a POST request comes through AJP and the request exceeds the max-post-size limit (maxEntitySize), Undertow's AjpServerRequestConduit implementation closes…
PriorityP340high7.5CVSS 3.1
AVNACLPRNUINSUCNINAH
EPSS
0.87%
54.9th percentile
When a POST request comes through AJP and the request exceeds the max-post-size limit (maxEntitySize), Undertow's AjpServerRequestConduit implementation closes a connection without sending any response to the client/proxy. This behavior results in that a front-end proxy marking the backend worker (application server) as an error state and not forward requests to the worker for a while. In mod_cluster, this continues until the next STATUS request (10 seconds intervals) from the application server updates the server state. So, in the worst case, it can result in "All workers are in error state" and mod_cluster responds "503 Service Unavailable" for a while (up to 10 seconds). In mod_proxy_balancer, it does not forward requests to the worker until the "retry" timeout passes. However, luckily, mod_proxy_balancer has "forcerecovery" setting (On by default; this parameter can force the immediate recovery of all workers without considering the retry parameter of the workers if all workers of a balancer are in error state.). So, unlike mod_cluster, mod_proxy_balancer does not result in responding "503 Service Unavailable". An attacker could use this behavior to send a malicious request and trigger server errors, resulting in DoS (denial of service). This flaw was fixed in Undertow 2.2.19.Final, Undertow 2.3.0.Alpha2.
Affected
6 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | undertow | < undertow 2.2.18-1 (forky) | undertow 2.2.18-1 (forky) |
| redhat | jboss_fuse | — | — |
| redhat | undertow | < 2.2.19 | 2.2.19 |
| redhat | undertow | — | — |
| redhat | undertow | — | — |
| redhat | undertow | >= 0 < 2.2.18-1 | 2.2.18-1 |
CVSS provenance
nvdv3.17.5HIGHCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
osv7.5HIGH
vendor_debian7.5HIGH
vendor_oracle7.5HIGH
vendor_redhat7.5HIGH
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
GHSA
Undertow vulnerable to Dos via Large AJP request
ghsa·2022-08-06
CVE-2022-2053 [HIGH] CWE-400 Undertow vulnerable to Dos via Large AJP request
Undertow vulnerable to Dos via Large AJP request
When a POST request comes through AJP and the request exceeds the max-post-size limit (maxEntitySize), Undertow's AjpServerRequestConduit implementation closes a connection without sending any response to the client/proxy. This behavior results in that a front-end proxy marking the backend worker (application server) as an error state and not forward requests to the worker for a while. In mod_cluster, this continues until the next STATUS request (10 seconds intervals) from the application server updates the server state. So, in the worst case, it can result in "All workers are in error state" and mod_cluster responds "503 Service Unavailable" for a while (up to 10 seconds). In mod_proxy_balancer, it does not forward requests to the worker u
OSV
Undertow vulnerable to Dos via Large AJP request
osv·2022-08-06
CVE-2022-2053 [HIGH] Undertow vulnerable to Dos via Large AJP request
Undertow vulnerable to Dos via Large AJP request
When a POST request comes through AJP and the request exceeds the max-post-size limit (maxEntitySize), Undertow's AjpServerRequestConduit implementation closes a connection without sending any response to the client/proxy. This behavior results in that a front-end proxy marking the backend worker (application server) as an error state and not forward requests to the worker for a while. In mod_cluster, this continues until the next STATUS request (10 seconds intervals) from the application server updates the server state. So, in the worst case, it can result in "All workers are in error state" and mod_cluster responds "503 Service Unavailable" for a while (up to 10 seconds). In mod_proxy_balancer, it does not forward requests to the worker u
OSV
CVE-2022-2053: When a POST request comes through AJP and the request exceeds the max-post-size limit (maxEntitySize), Undertow's AjpServerRequestConduit implementati
osv·2022-08-05·CVSS 7.5
CVE-2022-2053 [HIGH] CVE-2022-2053: When a POST request comes through AJP and the request exceeds the max-post-size limit (maxEntitySize), Undertow's AjpServerRequestConduit implementati
When a POST request comes through AJP and the request exceeds the max-post-size limit (maxEntitySize), Undertow's AjpServerRequestConduit implementation closes a connection without sending any response to the client/proxy. This behavior results in that a front-end proxy marking the backend worker (application server) as an error state and not forward requests to the worker for a while. In mod_cluster, this continues until the next STATUS request (10 seconds intervals) from the application server updates the server state. So, in the worst case, it can result in "All workers are in error state" and mod_cluster responds "503 Service Unavailable" for a while (up to 10 seconds). In mod_proxy_balancer, it does not forward requests to the worker until the "retry" timeout passes. However, luckily,
Oracle
Oracle Oracle Communications Risk Matrix: Signaling (Undertow) — CVE-2022-2053
vendor_oracle·2023-01-15·CVSS 7.5
CVE-2022-2053 [HIGH] Oracle Oracle Communications Risk Matrix: Signaling (Undertow) — CVE-2022-2053
Oracle Oracle Communications Risk Matrix: Signaling (Undertow) vulnerability
CVE: CVE-2022-2053
CVSS: 7.5
Protocol: HTTP
Remote exploit: Yes
Affected versions: Network
Advisory: cpujan2023 (JAN 2023)
Red Hat
undertow: Large AJP request may cause DoS
vendor_redhat·2022-06-14·CVSS 7.5
CVE-2022-2053 [HIGH] CWE-400 undertow: Large AJP request may cause DoS
undertow: Large AJP request may cause DoS
When a POST request comes through AJP and the request exceeds the max-post-size limit (maxEntitySize), Undertow's AjpServerRequestConduit implementation closes a connection without sending any response to the client/proxy. This behavior results in that a front-end proxy marking the backend worker (application server) as an error state and not forward requests to the worker for a while. In mod_cluster, this continues until the next STATUS request (10 seconds intervals) from the application server updates the server state. So, in the worst case, it can result in "All workers are in error state" and mod_cluster responds "503 Service Unavailable" for a while (up to 10 seconds). In mod_proxy_balancer, it does not forward requests to the worker until th
Debian
CVE-2022-2053: undertow - When a POST request comes through AJP and the request exceeds the max-post-size ...
vendor_debian·2022·CVSS 7.5
CVE-2022-2053 [HIGH] CVE-2022-2053: undertow - When a POST request comes through AJP and the request exceeds the max-post-size ...
When a POST request comes through AJP and the request exceeds the max-post-size limit (maxEntitySize), Undertow's AjpServerRequestConduit implementation closes a connection without sending any response to the client/proxy. This behavior results in that a front-end proxy marking the backend worker (application server) as an error state and not forward requests to the worker for a while. In mod_cluster, this continues until the next STATUS request (10 seconds intervals) from the application server updates the server state. So, in the worst case, it can result in "All workers are in error state" and mod_cluster responds "503 Service Unavailable" for a while (up to 10 seconds). In mod_proxy_balancer, it does not forward requests to the worker until the "retry" timeout passes. However, luckily,
No detection rules found.
No public exploits indexed.
No writeups or analysis indexed.
2022-08-05
Published