https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 04:22:33 +0000 https://cve.radiocsirt.org/vuln/euvd-2026-12124 EUVD-2026-12124 https://cve.radiocsirt.org/vuln/euvd-2026-12124 https://cve.radiocsirt.org/vuln/fkie_cve-2022-2053 <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>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/fkie_cve-2022-2053 https://cve.radiocsirt.org/vuln/ghsa-95rf-557x-44g5 <p><strong>Affected:</strong> Maven: io.undertow:undertow-core</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> Maven: io.undertow:undertow-core</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/ghsa-95rf-557x-44g5 https://cve.radiocsirt.org/vuln/gsd-2022-2053 gsd-2022-2053 https://cve.radiocsirt.org/vuln/gsd-2022-2053 https://cve.radiocsirt.org/vuln/rhsa-2022:6821 <p>undertow: potential security issue in flow control over HTTP/2 may lead to DOS(incomplete fix for CVE-2021-3629) undertow: Large AJP request may cause DoS snakeyaml: Denial of Service due to missing nested depth limitation for collections</p> <p>undertow: potential security issue in flow control over HTTP/2 may lead to DOS(incomplete fix for CVE-2021-3629) undertow: Large AJP request may cause DoS snakeyaml: Denial of Service due to missing nested depth limitation for collections</p> https://cve.radiocsirt.org/vuln/rhsa-2022:6821 https://cve.radiocsirt.org/vuln/ubuntu-cve-2022-2053 <p><strong>Affected:</strong> Ubuntu:Pro:16.04:LTS: undertow, Ubuntu:Pro:18.04:LTS: undertow, Ubuntu:Pro:20.04:LTS: undertow, Ubuntu:Pro:22.04:LTS: undertow, Ubuntu:Pro:24.04:LTS: undertow, Ubuntu:25.10: undertow, Ubuntu:26.04:LTS: 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> Ubuntu:Pro:16.04:LTS: undertow, Ubuntu:Pro:18.04:LTS: undertow, Ubuntu:Pro:20.04:LTS: undertow, Ubuntu:Pro:22.04:LTS: undertow, Ubuntu:Pro:24.04:LTS: undertow, Ubuntu:25.10: undertow, Ubuntu:26.04:LTS: 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/ubuntu-cve-2022-2053 https://cve.radiocsirt.org/vuln/wid-sec-w-2022-1636 <p>Ein entfernter, anonymer Angreifer kann mehrere Schwachstellen in Red Hat JBoss Enterprise Application Platform und Red Hat Enterprise Linux ausnutzen, um einen Denial of Service Angriff durchzuführen.</p> <p>Ein entfernter, anonymer Angreifer kann mehrere Schwachstellen in Red Hat JBoss Enterprise Application Platform und Red Hat Enterprise Linux ausnutzen, um einen Denial of Service Angriff durchzuführen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2022-1636