https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 05 Oct 2026 20:12:13 +0000 https://cve.radiocsirt.org/vuln/cve-2022-2053 <p><strong>Affected:</strong> Undertow</p> <p>When a POST request comes through AJP and the request exceeds the max-post-size limit (maxEntitySize), Undertow&#39;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 &#34;All workers are in error state&#34; and mod_cluster responds &#34;503 Service Unavailable&#34; for a while (up to 10 seconds). In mod_proxy_balancer, it does not forward requests to the worker until the &#34;retry&#34; timeout passes. However, luckily, mod_proxy_balancer has &#34;forcerecovery&#34; 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 &#34;503 Service Unavailable&#34;. 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.</p> <p><strong>Affected:</strong> Undertow</p> <p>When a POST request comes through AJP and the request exceeds the max-post-size limit (maxEntitySize), Undertow&#39;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 &#34;All workers are in error state&#34; and mod_cluster responds &#34;503 Service Unavailable&#34; for a while (up to 10 seconds). In mod_proxy_balancer, it does not forward requests to the worker until the &#34;retry&#34; timeout passes. However, luckily, mod_proxy_balancer has &#34;forcerecovery&#34; 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 &#34;503 Service Unavailable&#34;. 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.</p> https://cve.radiocsirt.org/vuln/cve-2022-2053