CVSS: 7.5EPSS: 81%CPEs: 444EXPL: 7CVE-2023-44487 – HTTP/2 Rapid Reset Attack Vulnerability
https://notcve.org/view.php?id=CVE-2023-44487
The HTTP/2 protocol allows a denial of service (server resource consumption) because request cancellation can reset many streams quickly, as exploited in the wild in August through October 2023. El protocolo HTTP/2 permite una denegación de servicio (consumo de recursos del servidor) porque la cancelación de solicitudes puede restablecer muchas transmisiones rápidamente, como se explotó en la naturaleza entre agosto y octubre de 2023. A flaw was found in handling multiplexed streams in the HTTP/2 protocol. A client can repeatedly make a request for a new multiplex stream and immediately send an RST_STREAM frame to cancel it. This creates extra work for the server setting up and tearing down the streams while not hitting any server-side limit for the maximum number of active streams per connection, resulting in a denial of service due to server resource consumption. • https://github.com/imabee101/CVE-2023-44487 https://github.com/studiogangster/CVE-2023-44487 https://github.com/bcdannyboy/CVE-2023-44487 https://github.com/sigridou/CVE-2023-44487- https://github.com/ByteHackr/CVE-2023-44487 https://github.com/ReToCode/golang-CVE-2023-44487 http://www.openwall.com/lists/oss-security/2023/10/13/4 http://www.openwall.com/lists/oss-security/2023/10/13/9 http://www.openwall.com/lists/oss-security/2023/10/18/4 http://www. • CWE-400: Uncontrolled Resource Consumption •
CVSS: 7.5EPSS: 0%CPEs: 29EXPL: 0CVE-2023-1108 – Undertow: infinite loop in sslconduit during close
https://notcve.org/view.php?id=CVE-2023-1108
A flaw was found in undertow. This issue makes achieving a denial of service possible due to an unexpected handshake status updated in SslConduit, where the loop never terminates. Se encontró una falla en undertow. Este problema hace posible lograr una denegación de servicio debido a un estado de protocolo de enlace inesperado actualizado en SslConduit, donde el bucle nunca termina • https://access.redhat.com/errata/RHSA-2023:1184 https://access.redhat.com/errata/RHSA-2023:1185 https://access.redhat.com/errata/RHSA-2023:1512 https://access.redhat.com/errata/RHSA-2023:1513 https://access.redhat.com/errata/RHSA-2023:1514 https://access.redhat.com/errata/RHSA-2023:1516 https://access.redhat.com/errata/RHSA-2023:2135 https://access.redhat.com/errata/RHSA-2023:3883 https://access.redhat.com/errata/RHSA-2023:3884 https://access.redhat.com/errata/RHSA • CWE-835: Loop with Unreachable Exit Condition ('Infinite Loop') •
CVSS: 7.5EPSS: 0%CPEs: 10EXPL: 0CVE-2022-4492 – undertow: Server identity in https connection is not checked by the undertow client
https://notcve.org/view.php?id=CVE-2022-4492
The undertow client is not checking the server identity presented by the server certificate in https connections. This is a compulsory step (at least it should be performed by default) in https and in http/2. I would add it to any TLS client protocol. A flaw was found in undertow. The undertow client is not checking the server identity the server certificate presents in HTTPS connections. • https://access.redhat.com/security/cve/CVE-2022-4492 https://bugzilla.redhat.com/show_bug.cgi?id=2153260 https://security.netapp.com/advisory/ntap-20230324-0002 • CWE-550: Server-generated Error Message Containing Sensitive Information •
CVSS: 4.9EPSS: 0%CPEs: 13EXPL: 0CVE-2022-2764 – Undertow: DoS can be achieved as Undertow server waits for the LAST_CHUNK forever for EJB invocations
https://notcve.org/view.php?id=CVE-2022-2764
A flaw was found in Undertow. Denial of service can be achieved as Undertow server waits for the LAST_CHUNK forever for EJB invocations. Se ha encontrado un fallo en Undertow. Puede producirse una denegación de servicio ya que el servidor de Undertow espera eternamente el LAST_CHUNK para las invocaciones EJB A flaw was found in Undertow with EJB invocations. This flaw allows an attacker to generate a valid HTTP request and send it to the server on an established connection after removing the LAST_CHUNK from the bytes, causing a denial of service. • https://bugzilla.redhat.com/show_bug.cgi?id=2117506 https://security.netapp.com/advisory/ntap-20221014-0006 https://access.redhat.com/security/cve/CVE-2022-2764 • CWE-400: Uncontrolled Resource Consumption •
CVSS: 7.5EPSS: 0%CPEs: 4EXPL: 0CVE-2022-2053 – undertow: Large AJP request may cause DoS
https://notcve.org/view.php?id=CVE-2022-2053
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. • https://bugzilla.redhat.com/show_bug.cgi?id=2095862&comment#0 https://issues.redhat.com/browse/UNDERTOW-2133 https://access.redhat.com/security/cve/CVE-2022-2053 https://bugzilla.redhat.com/show_bug.cgi?id=2095862 • CWE-400: Uncontrolled Resource Consumption CWE-770: Allocation of Resources Without Limits or Throttling •