Jason Lee

**Name of the Vulnerable Software and Affected Versions** Undertow versions prior to 2.2.19.Final Undertow versions prior to 2.3.0.Alpha2 **Description** 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.). An attacker could use this behavior to send a malicious request and trigger server errors, resulting in DoS (denial of service). **Recommendations** For Undertow versions prior to 2.2.19.Final, update to Undertow 2.2.19.Final or later. For Undertow versions prior to 2.3.0.Alpha2, update to Undertow 2.3.0.Alpha2 or later.

**Name of the Vulnerable Software and Affected Versions** curl version 7.65.2 **Description** The issue is related to an integer overflow vulnerability in the `tool operate.c` file of curl, which can occur when a large value is specified as the retry delay. This may cause a denial of service to associated systems or networks if the `--retry-delay` is misinterpreted as a value much smaller than intended. However, many parties report that this has no direct security impact on the curl user. The vulnerability may be exploited to cause a denial of service, but this is not especially plausible as it only happens if the user was trying to specify that curl should wait weeks or longer before trying to recover from a transient error. **Recommendations** For curl version 7.65.2, consider updating to a newer version to mitigate the risk of exploitation, although the security impact of this issue is disputed. As a temporary workaround, consider avoiding the use of large values for the `--retry-delay` option to minimize the risk of denial of service.