4 results (0.007 seconds)

CVSS: 7.5EPSS: 0%CPEs: 29EXPL: 0

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: 4.9EPSS: 0%CPEs: 13EXPL: 0

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: 0

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 •

CVSS: 7.5EPSS: 0%CPEs: 15EXPL: 0

A flaw was found in Undertow. For an AJP 400 response, EAP 7 is improperly sending two response packets, and those packets have the reuse flag set even though JBoss EAP closes the connection. A failure occurs when the connection is reused after a 400 by CPING since it reads in the second SEND_HEADERS response packet instead of a CPONG. Se ha encontrado un fallo en Undertow. Para una respuesta AJP 400, EAP 7 envía inapropiadamente el flag de reúso habilitado aunque JBoss EAP cierra la conexión. es producido un fallo cuando la conexión es reusada después de un 400 por CPING ya que lee en el segundo paquete de respuesta SEND_HEADERS en lugar de un CPONG • https://access.redhat.com/security/cve/CVE-2022-1319 https://bugzilla.redhat.com/show_bug.cgi?id=2073890 https://github.com/undertow-io/undertow/commit/1443a1a2bbb8e32e56788109d8285db250d55c8b https://github.com/undertow-io/undertow/commit/7c5b3ab885b5638fd3f1e8a935d5063d68aa2df3 https://issues.redhat.com/browse/UNDERTOW-2060 https://security.netapp.com/advisory/ntap-20221014-0006 • CWE-252: Unchecked Return Value •